Простой пример. Сейчас очень часто приходится слышать о том, что якобы, композиция лучше наследования, и это декларируется как некий «общий» принцип проектирования.
Вот тут есть простой пример: http://info.javarush.ru/translation/2014/06/26/Наследование-против-композиции...
Это пример на Java, и автор, совершенно справедливо, указывает на проблемы, которые возникают с наследованием. В результате, ему приходится городить интерфейс, еще один класс, и композицию. Логически, с точки зрения иерархии, это выглядит немного нелепо, у нас как бы, пчела уже не насекомое, а какая-то отдельная хрень, но проблемы, чисто технические, он вроде как решает.
Однако, мы можем задаться вопросом, а не являются ли эти проблемы, проблемами специфичными для его среды? Не рановато ли нам обобщать данные утверждения?
Insect := Object clone do(
move := method("move" println)
attack := method(move; "attack" println)
)
Bee := Insect clone do(
move := method("fly" println)
attack := method(resend)// этот метод просто для эквивалентности, его можно было бы вообще убрать, это глупость.
)
bee := Bee clone
bee attack
#>>>> fly
#>>>> attack
Упс. Для Io данное утверждение не справедливо, тут все работает. Следовательно что? А то что тезис «Композиция лучше наследования» должен звучать как для группы языков «Композиция лучше наследования для некоторой группы языков, а для другой группы — наоборот». Не следует употреблять такие общие понятия как «ООП», «Проектирование», когда речь идет лишь о частных случаях.
Вот и человек, несколькими тредами ниже, слегка запутался, и *думает*, что он плодит овермиллион классов «в угоду проектирования», тогда как он это делает по причине среды программирования.
Не стоит слишком увлекаться обобщениями, друзья.
