Функции расширения Kotlin для разделения больших классов - PullRequest
0 голосов
/ 29 октября 2018

Недавно в моей компании начались дебаты после рассмотрения другого подхода к написанию тяжелых классов.

Большой класс Java, содержащий специфичную для компонентов логику (никаких стандартных принципов ООП не имело смысла), должен был быть переписан в Kotlin. Предложенным решением было разделение логики по категориям и категориям на отдельные файлы с внутренними функциями расширения для основного класса.

Пример:

Main.kt
class BigClass {
  // internal fields exposed to the extension functions in different files

  // Some main logic here
}


BusinessLogic.kt
internal fun BigClass.handleBussinessCase() {
 // Complex business logic handled here accessing the exposed internal fields from BigClass
}

Что вы думаете об этом? Я не видел, чтобы он использовался где-то, может быть, по уважительной причине, но альтернатива тысяч строк классов кажется хуже.

Ответы [ 2 ]

0 голосов
/ 29 октября 2018

Вы должны учитывать, что функция расширения - это не что иное, как функция с неявным первым параметром, на который ссылается this.

Так что в вашем случае у вас будет что-то вроде:

internal fun handleBussinessCase(ref: BigClass)

, что означает Java :

static void handleBussinessCase(BigClass ref)

Но можно предположить, что это шаблон делегата, который может быть инкапсулирован намного лучше в Kotlin .

Поскольку в любом случае свойства должны быть внутренними , вы можете просто вставить их как data class в меньшие варианты использования. Если вы определите интерфейс вокруг них (который сделает свойства public все же), вы можете создать с ним шаблон делегата и при этом ссылаться на каждое свойство с помощью this в вашей реализации.

0 голосов
/ 29 октября 2018

Вот некоторые мысли по созданию функций расширения для класса:

  • Это будет служебная функция, которая будет работать с расширяемым объектом, это не будет объектная функция, то есть она будет иметь доступ только к public методам и свойствам;
  • Если вы планируете использовать класс, который был расширен в модульных тестах, эти методы (расширения) будет труднее имитировать;
  • Скорее всего, они не будут вести себя так, как вы ожидаете при использовании с унаследованными объектами.

Может быть, я что-то пропустил, поэтому, пожалуйста, прочитайте больше о расширениях здесь .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...