Но ведь аналогично и изменения в интерфейсе требуют изменений имплементирующих его классов.
Эти классы перестанут соответствовать интерфейсу, но останутся вполне рабочими.
Вообще я не согласен с статьей, что наследование вообще надо выкинуть или использовать по минимуму, автор немного нагнетает истерику, но я согласен, что наследование стоит использовать только когда именно оно лучше всего подходит, а не агрегирование или, например, паттерн decorator.
Теоретически (мне кажется), наследование публичного интерфейса надёжнее, чем приватного.
***
2) Реально изменить поведение предка можно только с помощью перекрытия виртуальных методов;
3) Принцип подстановки Лисков обязывает класс-потомок удовлетворять всем требованиям к классу-предку;
4) Для выполнения пункта 2 в точном соответствии с пунктом 3 классу-потомку необходима полная информация о времени вызова и реализации перекрытого виртуального метода;
5)Информация из пункта 4 зависит от реализации класса-предка, включая приватные члены и их код.
Что автор имел в виду под "...еобходима полная информация о времени вызова..."?
Также автор упустил тот момент, что обычно классы никто не проектирует. Они появляются сами в ходе секса в жалких попытках решить какую-то проблему. Поэтому говорить надо не о проектировании класса, а о том как фигачить код так, чтобы сама по себе получалось подобие структуры.
Тут надо и не переборщить (если всё сделать приватным и sealed/final, то ФИГАЧИТЬ не получится), если же совсем распоясатсья - получится динамическая лапша типа JS, так что тут нужно разбираться в сортах говнокода и понимать, говнокод какого вкуса тебе в данный момент приятней жрать
Еще очень важно, что т.к. никто не имеет в голове четкой архитектуры, её наличие заменяется runtime reflection. Например, ты не можешь понять, какие у класса должны быть поля, но ты можешь пойти и рефлекшеном собрать все классы из пакета, сложить в коллекцию и считать эту коллекцию «набором полей».
Поэтому очень важно, чтобы рефлекшеном можно было вмешаться в любой говнокодерский механизм и пофиксить так, чтобы начало работать. Если же сделать истинно приватные фиксированные структуры или запретить рефлекшен, сразу случится коллапс, говнокод перестанет работать и починить его станет никак. Дальше идут всякие джава агенты, аннотейшен-процессоры, автогенераторы и макросы
Главное не докатиться то JS. Нет ничего более беспомощного, безответственного и испорченного, чем JS зомби, пишущие JS лапшу. «Я знал, что рано или поздно мы перейдем и на эту дрянь.»
Любой кто хоть раз зарепортил 28 календарных дней на изучение структуры приложения в отладчике с целью фикса проблемы в рантайме, поймет о чем тут речь.
Хорошее ООП это хорошо, но код пишешь НЕ ТЫ. В основном, ты склеиваешь на синюю изоленту миллиарды классов, написанные натруженными индусскими ногами, добавляешь к этой горе жалкую горсточку из нескольких сотен/тысяч своих классов, и всё. Ты уже жрешь говно, и тебе надо уметь выживать в этом
т.к. никто не имеет в голове четкой архитектуры, её наличие заменяется runtime reflection. Например, ты не можешь понять, какие у класса должны быть поля, но ты можешь пойти и рефлекшеном собрать все классы из пакета, сложить в коллекцию и считать эту коллекцию «набором полей». Поэтому очень важно, чтобы рефлекшеном можно было вмешаться в любой говнокодерский механизм и пофиксить так, чтобы начало работать. Если же сделать истинно приватные фиксированные структуры или запретить рефлекшен, сразу случится коллапс, говнокод перестанет работать и починить его станет никак. Дальше идут всякие джава агенты, аннотейшен-процессоры, автогенераторы и макросы
Я нихрена не понял, но хочется спросить, а ревью у вас делается? Если делается, как ревьюер реагирует на тот бред, что ты описал?
не очень понятно, чего там автор хотел сказать. Что реализация интерфейсов в принципе гибче наследования реальных классов? Дык очевидно. Что наследоваться от реальных классов вообще нельзя? На практике следование сему подходу может быть очень неудобно.
когда нужно несколько почти одинаковых классов, имеющих множество методов, но различающихся только в реализации одного-двух из них. Если у нас есть только абстрактные интерфейсы, то привет копипаста.
Канонический наивный пример - собачка делает «ав-ав», коровка «му-му», кошечка «мяу», но они при всей своей разнице обладают одинаковыми методами четвероногого сухопутного млекопитающего.
Есть сообщения, которые можно отправлять любому объекту, и как объект на него отреагирует, зависит только от него. Сообщения могут быть любыми.
Метод в смолтоке - лишь установленная в объекте реакция на конкретное сообщение, но отсутствие того или иного метода не запрещает слать объекту другие сообщения.
там какое то говно написано. Автор думает что обсуждает ООП, а что такое ООП он не знает. Да и Java к ООП отношения, собственно говоря, не имеет, это квазиооп
Ну так, в Io получается, что любые поля можно сделать любыми — хоть public, хоть приват, хоть какими угодно кастомными, потому что там есть доступ к объекту вызова и отсылателю сообщения
Foo := Object clone do(
bar := method(
if(call sender self isKindOf(Foo), "ok" println, "you are not subclass of Foo" println)
)
)
SubFoo := Foo clone do(
baz := method(bar)
)
Another := Object clone do(
baz := method(Foo bar)
)
foo := SubFoo clone
another := Another clone
foo baz // ok
another baz // you are not subclass of Foo