Форумы портала PHP.SU » Разное » Обсуждение статей » обсуждение принципов ООП и шаблонов

Страниц (1): [1]
 

1. DlTA - 06 Декабря, 2012 - 02:39:10 - перейти к сообщению
EuGen, я прошу не прикрывать эту тему. я понимаю что обсуждение прошлой зашло не в ту сторону, но таки хочется догребсти до истены.

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

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

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

из предыстории: был класс утки, имевший методы плавать и крякать, заставили добавить метод летать, что в итоге привело к тому, что полетели резиновые утки, класс которых был наследован от класса уток.
вот тут я не могу понять одной вещи, если класс обладает неким методом, код использующий/вызывающий(по необходимости) метод этого объекта, а в примере в итоге класс уток лешили метода крякать и летать вынеся их во вне, вот никак не могу понять, как такое вообще можно отделять, ведь это часть общего,
хотя вопрос скорее состоит в том, что вообще может быть вложено в методы летать и крякать?
2. caballero - 06 Декабря, 2012 - 03:47:36 - перейти к сообщению
в PHP5.4 трейты добавили - поэтому тут как раз все просто - сунул в класс и все дела.

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

поэтому в реальности большинство програмеров просто сделает копипаст метода летать вместо городить для одного метода отдельный класс да еще и интерфейс. В теории это некрасиво но на практике вполне сгодится потому как в реальности количество разновидностей объектов редко превышает полдесятка. А когда превышает то там уже будет такой винегрет что никакие паттерны не помогут.
3. DlTA - 06 Декабря, 2012 - 09:05:56 - перейти к сообщению
тото я смотрю хрень какая то,
хотя к примеру когда кодил на С# то там все прям требуедт подобного кода,
мол вот вам х..ва куча объектов раскиданная по разным пространствам имен, хотите использовать подключайте/создавайте и вперед.

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

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

в общем как то сложно воспринимается.
4. EuGen - 06 Декабря, 2012 - 09:07:58 - перейти к сообщению
В реальности "летать" - может быть в разных вариациях. Реактивная тяга/разность температур и плотности сред (дирижабль)/закон Бернулли (подъемная сила крыла)/винтовая тяга (турбины/винты/вертолеты) и т.п. - даже я, не обладающий специальными знаниями в аэротехнике и аэродинамике, сходу вспомнил 4 способа для реализации полета.
И как раз дело в том, что, абстрагируясь от реальных условий, создать что-то рабочее не всегда возможно. Однако в соответствии с теорией можно сделать некий абстрактый класс полета или снабдить его интерфейсом и пусть "утка" реализует этот интерфейс (благо класс может реализовывать их сколько угодно). Но - важно: реализация-то все равно будет сделана внутри класса "утки". Это то, о чем сказано в комментарии выше (я про разность абстракции и конкретной модели, которая есть на практике)
5. caballero - 06 Декабря, 2012 - 10:12:25 - перейти к сообщению
Цитата:
кстати если еще раз обратиться к тому же примеру из книги, там базовый класс подлежал модификации так как в него были добавлены методы добавления объектов поведения,


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

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

Это все напоминает фигуры высшего пилотажа на авиашоу - выглядит замечательно, демонстрирует возможности самолета и все такое, вот только в реальном бою с этих выкрутасов настолько мало пользы что их даже не изучают в летных училищах.
6. DlTA - 06 Декабря, 2012 - 10:34:26 - перейти к сообщению
шаблон наблюдатель
1) имхо жутко неудачное название ведь на самом деле никто не наблюдает, все дружненько пришли, оставили свои контакты и все, оповещение проходит по решению "наблюдаемого" объекта.
2) я не знаю как в ява, но в пыхе для того чтоб зарегистрировать "контакты" было бы удачней использовать лямбда функции, при условии что метод соответсвует положенному интерфейсу.
7. caballero - 06 Декабря, 2012 - 12:30:49 - перейти к сообщению
Цитата:
я не знаю как в ява, но в пыхе для того чтоб зарегистрировать "контакты" было бы удачней использовать лямбда функции, при условии что метод соответсвует положенному интерфейсу.

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

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

поэтому самое простое - передавать каллбак функцию по имени и складывть это в массив
клас будет пробегать по массиву и дергать калбаки
8. DlTA - 06 Декабря, 2012 - 17:47:16 - перейти к сообщению
caballero пишет:
поэтому самое простое - передавать каллбак функцию по имени и складывть это в массив
клас будет пробегать по массиву и дергать калбаки
я о этом же

 

Powered by ExBB FM 1.0 RC1