Можно ли заставить два класса реализовать одни и те же имена полей, но разного типа во время компиляции?

Question

Допустим, есть два параллельных класса:

class A(
        val stringField: String,
        val intField: Int,
        val floatField: Float
)

class B(
        val stringField: Boolean,
        val intField: Boolean,
        val floatField: Boolean
)

Обратите внимание, что оба класса имеют одинаковое поле имена , но их типы различаются .

Мне было интересно, можно ли каким-то образом применить во время компиляции , чтобы он не компилировался, когда у класса A есть имя поля, которого у класса B нет .

Во время выполнения я, вероятно, мог бы использовать какое-нибудь отражение, чтобы обеспечить это, но мне искренне любопытно, возможно ли это во время компиляции, и я бы также предпочел не прибегать к отражению для этого.

РЕДАКТИРОВАТЬ 1: Теперь я вижу, что универсальные шаблоны, вероятно, являются частью решения здесь, но в реальном случае класс сценария A имеет много полей разных типов, а в классе B все поля всегда имеют тип Boolean. В идеале мне не нужно добавлять общий c для каждого другого типа поля, используемого в классе A

EDIT 2: Дополнительные сведения о рассматриваемом варианте использования:

Мне нужно преобразовать объект Full в объект Partial на основе некоторого Configuration (поля с конфигурацией false должны в конечном итоге оказаться null в объекте Partial). Эти три класса очень похожи друг на друга, поэтому я хотел наложить на них контракт (чтобы они не перестали синхронизироваться c с течением времени).

class Full(
        val stringField: String,
        val intField: Int,
        val floatField: Float,
        ...
)

class Partial(
        val stringField: String?,
        val intField: Int?,
        val floatField: Float?,
        ...
)

class Configuration(
        val stringField: Boolean,
        val intField: Boolean,
        val floatField: Boolean,
        ...
)

Answer 1

Это не проверка во время компиляции, но вы всегда можете написать тест, который применяет это ограничение.

Я, например, написал тест, который находит все функции, украшенные моей аннотацией DSL, и проверяет, что все они описаны в нашей do c (да! Тестирование документации!).

Вы можете использовать библиотеку Reflection , что делает работу с отражением более увлекательной (kotlin -отражение уже хорошо но все же ...).