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

после сегодняшних (уже вчерашних) баталий по вопросу шаблонов проектирования я понял что чегото я не понял, нарыл упомянутую книгу "Фримен Эр., Фримен Эл., Сьерра К., Бейтс Б. Паттерны проектирования (2011)"

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

к примеру та же задача с утками рассматриваемая в начале

из предыстории: был класс утки, имевший методы плавать и крякать, заставили добавить метод летать, что в итоге привело к тому, что полетели резиновые утки, класс которых был наследован от класса уток.
вот тут я не могу понять одной вещи, если класс обладает неким методом, код использующий/вызывающий(по необходимости) метод этого объекта, а в примере в итоге класс уток лешили метода крякать и летать вынеся их во вне, вот никак не могу понять, как такое вообще можно отделять, ведь это часть общего,
хотя вопрос скорее состоит в том, что вообще может быть вложено в методы летать и крякать?

в PHP5.4 трейты добавили - поэтому тут как раз все просто - сунул в класс и все дела.

что касается задачи, там действительно неувязка - класс реализующий полеты ничего не знает об самой утке.
в книжной теории этого и не надо - вот метод поведения - дергайте его и наслаждайтесть. Но к реальной практике такое програмирование отношения не имеет - маловероятно запрограмировать реализацию полетов ничего не зная о самой утке и не имея доступа к ее свойствам. То есть при создании объекма класса поведения ему придется передавать ссылку на сам базовый класс утки. А в этом случае получаем перекрестную зависимость между классами (точнее интерфейсами) что тоже не есть хорошо.

поэтому в реальности большинство програмеров просто сделает копипаст метода летать вместо городить для одного метода отдельный класс да еще и интерфейс. В теории это некрасиво но на практике вполне сгодится потому как в реальности количество разновидностей объектов редко превышает полдесятка. А когда превышает то там уже будет такой винегрет что никакие паттерны не помогут.

тото я смотрю хрень какая то,
хотя к примеру когда кодил на С# то там все прям требуедт подобного кода,
мол вот вам х..ва куча объектов раскиданная по разным пространствам имен, хотите использовать подключайте/создавайте и вперед.

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

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

в общем как то сложно воспринимается.

В реальности "летать" - может быть в разных вариациях. Реактивная тяга/разность температур и плотности сред (дирижабль)/закон Бернулли (подъемная сила крыла)/винтовая тяга (турбины/винты/вертолеты) и т.п. - даже я, не обладающий специальными знаниями в аэротехнике и аэродинамике, сходу вспомнил 4 способа для реализации полета.
И как раз дело в том, что, абстрагируясь от реальных условий, создать что-то рабочее не всегда возможно. Однако в соответствии с теорией можно сделать некий абстрактый класс полета или снабдить его интерфейсом и пусть "утка" реализует этот интерфейс (благо класс может реализовывать их сколько угодно). Но - важно: реализация-то все равно будет сделана внутри класса "утки". Это то, о чем сказано в комментарии выше (я про разность абстракции и конкретной модели, которая есть на практике)

Ну, при добавлении нового функционала по любому придется добавлять код.
возможно дальше по книге, как конченные индусы они навернут на это еще пару паттернов и в результате вместо сайта-визитки придется писать джумлу (а заказчик платит только за сайт визитку).
Не говоря уже про то что копипаста (хоть и одной строки) все равно не избежать при имплементации интерфейсв и что объекты с динамическим поведением намного хуже отлаживать.

хотя книга неплохая - как минимум полезнно почитать какие вообще бывают варианты разруливания архитектурных проблем.

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

шаблон наблюдатель
1) имхо жутко неудачное название ведь на самом деле никто не наблюдает, все дружненько пришли, оставили свои контакты и все, оповещение проходит по решению "наблюдаемого" объекта.
2) я не знаю как в ява, но в пыхе для того чтоб зарегистрировать "контакты" было бы удачней использовать лямбда функции, при условии что метод соответсвует положенному интерфейсу.

в яве есть анонимные классы - там с этим не проблема

в пыхе замыкания какието недоделаные, в частности надо передавать явно переменные контекста внутрь функции

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

я о этом же