Composition vs Inheritance

[grigori]

теме 100 лет в обед, во всех книгах черным по белому написано: aggregation over inheritance
просто примите это, наконец

 

[grigori]

Мне кажется будет крайне сложно найти такой пример где нужен будет именно интерфейс с дефолт методами(вместо абстрактного класса). Эта всеобщая любовь к интерфейсам(относительно абстрактных классов) немного туманит рассуждения.

Я когда-то развлекался так на собеседованиях: спрашивал, в чем отличие абстрактного класса от интерфейса в php, сначала было весело - потом надоело.
Суть в том, что на низком уровне разницы нет, одинаковое копирование zval. Есть интерфейсы с реализацией методов. В расширении можно превратить одно в другое.

 

[grigori]

2) ты обновил библиотеку и в новой версии появился метод x()

не мешает

хренасе
когда в 7.2 зарезервировали Object, в yii пришлось перепиливать дохрена из-за наследования всего от базового класса с именем Obejct )))
назвать так базовый класс для всего было очередным гениальным решением, конечно, и батхерт был неслабый

 

[fixxxer]

Я когда-то развлекался так на собеседованиях: спрашивал, в чем отличие абстрактного класса от интерфейса в php, сначала было весело - потом надоело.

На такой вопрос я бы от senior-а или продвинутого миддла ожидал ответа, поясняющего семантическую разницу (abstract class = is-a, interface = can, ну или что-то эквивалентное типа abstract class = type, interface = feature), а рассуждения на тему множественного наследования или ключевых слов - это уровень джуниора или начинающего миддла.

А что там внутри php - да вообще наплевать, если я не ищу разработчика php-расширений. Знает - молодец, не знает - ну и не надо.

 

[grigori]

а в микросервисах выделять абстрактные классы нет смысла - при смене алгоритма или инфраструктуры проще переписать весь сервис целиком

 

[fixxxer]

Кто о чем, а @grigori о микросервисах.

В микросервисах есть интерфейсы. Какая разница, ключевым словом interface они описаны или в swagger-е каком-нибудь.

 

[Вурдалак]

с default methods как-то аккуратнее.

defaults methods не позволят это сделать: массив с событиями-то — состояние.

Я уже как-то говорил, что мне кажется, default methods — это своего рода хак. Можно было бы позволить наследовать несколько абстрактных классов, если они без состояния. Добавил состояние — нарушил BC. Или на крайняк ввести ключевое слово типа «primary abstract class» (или наоборот — «stateless abstract class»), которое бы позволяло разделать абстрактные классы на два типа.

Да и вообще, в реализации Java это именно «методы по умолчанию»: их нельзя сделать final, т.е. их всегда можно переопределить. Мне это не очень понятно.

 

[fixxxer]

defaults methods не позволят это сделать: массив с событиями-то — состояние.

Блин, да.

default methods — это своего рода хак

Не впервые. Generic-и с type erasure и лезущим отовсюду Object - тоже, по большому счету, хак.

Можно было бы позволить наследовать несколько абстрактных классов

Тогда интерфейсы становятся не нужны. Слишком революционно для Java, C++ какой-то получается

А вообще, конечно, все эти костыли (default methods, traits...) говорят о том, что изначальный постулат "множественное наследование не нужно, если есть интерфейсы" оказался неверен. Хотя, может, правильное направление тут - не решать проблему наследования, а упростить композицию, ну вон как в Kotlin?

 

[флоппик]

Я, кстати, считаю трейты (в таком виде, в каком они реализованы в PHP) ошибкой дизайна. Было бы намного лучше, если бы реализовали Java 8 default methods в интерфейсах (кажется, все разумные случаи использования трейтов сводятся к некоей дефолтной реализации определенного интерфейса).

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

Мне кажется будет крайне сложно найти такой пример где нужен будет именно интерфейс с дефолт методами(вместо абстрактного класса). Эта всеобщая любовь к интерфейсам(относительно абстрактных классов) немного туманит рассуждения.

class ConcreteApplication extends [abstract] BaseApplication implements MonitorableInterface, LoggableInterface, DebuggableInterface {
  use LoggerAwareTrait, MonitoringStatsTrait, ExposeEndpointsTrait...
}

 

[флоппик]

Я уже как-то говорил, что мне кажется, default methods — это своего рода хак. Можно было бы позволить наследовать несколько абстрактных классов, если они без состояния. Добавил состояние — нарушил BC. Или на крайняк ввести ключевое слово типа «primary abstract class» (или наоборот — «stateless abstract class»), которое бы позволяло разделать абстрактные классы на два типа.

Да и вообще, в реализации Java это именно «методы по умолчанию»: их нельзя сделать final, т.е. их всегда можно переопределить. Мне это не очень понятно.

Я тут поговорил с ява-девелопером, и он говорит, что ноги у дефолт-методов растут из другого места - они появились для того, что бы реализовать лямбды на классах нормально внутри JVM не ломая совместимость, типа, всякие Runnable { pubic run() } транслируются в свежей яве более адекватно внутри в лямбда-класс.

 

[Вурдалак]

Я тут поговорил с ява-девелопером, и он говорит, что ноги у дефолт-методов растут из другого места - они появились для того, что бы реализовать лямбды на классах нормально внутри JVM не ломая совместимость, типа, всякие Runnable { pubic run() } транслируются в свежей яве более адекватно внутри в лямбда-класс.

Да, они это сделали чтобы не ломать обратную совместимость. Но границы между stateless abstract class и interface with default methods стираются. А то почему они именно default и почему нельзя их сделать final — этот вопрос так и повисает в воздухе.