Форум dkLab и Denwer
Здесь общаются Web-разработчики.
Генеральный спонсор:
Хостинг «Джино»

Наследование и паттерн Стратегия (и не только) (dimagolov)
Author Message
Maus
Модератор



Joined: 29 Jun 2003
Posts: 8151
Карма: 271
   поощрить/наказать

Location: пос. Омсукчан Магаданской области

PostPosted: Thu Oct 08, 2009 8:33 pm ()
   Post subject:
Reply with quote


М

Выделено из темы «Вызов метода дочернего класса»,
расположенной в форуме Разное :: PHP (11 Октября 2009, 00:12).
Back to top
View user's profile Send private message
dimagolov
Участник форума



Joined: 04 Feb 2007
Posts: 1664
Карма: 96
   поощрить/наказать

Location: Christ Church, Barbados

PostPosted: Thu Oct 08, 2009 8:33 pm (спустя 1 секунду; написано за 5 минут 41 секунду)
   Post subject:
Reply with quote

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

Это делается через интерфейс и передачу "базовому" классу (т.е. контроллеру) объекта, который реализует некий интерфейс (т.е. модуля). Контроллеру ничего кроме интерфейса знать не нужно про реализацию модуля и подключение более позднего кода происходит без проблем.
Back to top
View user's profile Send private message
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 268
   поощрить/наказать

Location: Питер

PostPosted: Thu Oct 08, 2009 8:35 pm (спустя 2 минуты; написано за 20 секунд)
   Post subject:
Reply with quote

dimagolov
Вообще говоря, так очень даже делают. en.wikipedia.org/wiki/Strategy_pattern
Back to top
View user's profile Send private message
Maus
Модератор



Joined: 29 Jun 2003
Posts: 8151
Карма: 271
   поощрить/наказать

Location: пос. Омсукчан Магаданской области

PostPosted: Thu Oct 08, 2009 8:51 pm (спустя 15 минут; написано за 5 минут 20 секунд)
   Post subject:
Reply with quote

sv wrote:
Имелось ввиду функция косвенного вызова
Спасибо, определение мне известно. Просто колбэки рассматриваемого случая не касаются.
WingedFox wrote:
что мешает объявить в базовом классе метод
Мы до этого пункта ("как решать подобную задачу правильно") просто не добрались, застряли на обсуждении минусов текущего варианта.
Ваше решение имеет единственный минус: захламляет родителя и часть потомков методом, который им не нужен.
У топикстартера ошибка либо в иерархии, либо в логике (метод надо разбить на несколько). Без конкретики не ответить.

dimagolov
Это Вы не подумавши.
Back to top
View user's profile Send private message
dimagolov
Участник форума



Joined: 04 Feb 2007
Posts: 1664
Карма: 96
   поощрить/наказать

Location: Christ Church, Barbados

PostPosted: Thu Oct 08, 2009 10:32 pm (спустя 1 час 41 минуту; написано за 47 секунд)
   Post subject:
Reply with quote

Maus, что конкретно не подумавши? про "не должны использовать public или protected методов себя же", или про мое изложение "Стратегии"?






,
Back to top
View user's profile Send private message
Maus
Модератор



Joined: 29 Jun 2003
Posts: 8151
Карма: 271
   поощрить/наказать

Location: пос. Омсукчан Магаданской области

PostPosted: Thu Oct 08, 2009 11:20 pm (спустя 47 минут; написано за 44 секунды)
   Post subject:
Reply with quote

dimagolov
первое. В предельном случае получается, что на каждый чих надо порождать новый класс
Back to top
View user's profile Send private message
dimagolov
Участник форума



Joined: 04 Feb 2007
Posts: 1664
Карма: 96
   поощрить/наказать

Location: Christ Church, Barbados

PostPosted: Fri Oct 09, 2009 1:26 am (спустя 2 часа 6 минут; написано за 9 минут 18 секунд)
   Post subject:
Reply with quote

может вынесем это обсуждение в отдельный топик?

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

да, поддерживать такой код куда приятнее. соблюдай интерфейсы себе и об остальном можно и не думать особо.
Back to top
View user's profile Send private message
sv
Участник форума



Joined: 04 Jan 2004
Posts: 68
Карма: -7
   поощрить/наказать

Location: Россия

PostPosted: Fri Oct 09, 2009 8:49 am (спустя 7 часов 23 минуты; написано за 5 минут 44 секунды)
   Post subject:
Reply with quote

Maus wrote:
метод надо разбить на несколько
Именно с этого все и началось, да подобное вполне можно решить именно разбив метод на 2 части, отсюда и вышли ноги этого вопроса.
Подумал, что можно одним обойтись, и он автоматом будет вызывать дополнительный метод, чтобы не перегружать основной и не переписывать "кучу" одинакового кода.

Суть в том, что есть, скажем, 50 строк кода в методе, но этого не достаточно в некоторых классах потомках, и приходится либо перегружать и использовать все те же 50 строк кода и добавлять к ним еще 20, либо (а либо как оказалось, я выбрал неправильное).
То есть мое либо, это из пушки по воробьям.
dimagolov wrote:
может вынесем это обсуждение в отдельный топик?
Очень было бы интересно поучаствовать в обсуждении вопроса.
Back to top
View user's profile Send private message Send e-mail
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 268
   поощрить/наказать

Location: Питер

PostPosted: Fri Oct 09, 2009 10:10 am (спустя 1 час 20 минут; написано за 7 минут 8 секунд)
   Post subject:
Reply with quote

Maus wrote:
Ваше решение имеет единственный минус: захламляет родителя и часть потомков методом, который им не нужен.
Ну так и не нужно порождать потомков, которым этот метод не требуется. =)
Если есть вопрос выбора одного из нескольких способов обработки ситуации - это чистая "стратегия" и она выносится в отдельный набор классов.

dimagolov
Почитайте "Effective Java" Эккеля, разделы посвящённые ООП. Там очень хорошо об этом всём говорится, в частности "не наследуйтесь от классов, которые не были спроектированы специально для наследования".

sv
Есть хорошая книжка "Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию" Шаллоуея и Тротта, она даёт правильную базу для отказа от "глубокого" наследования. Помогает начать писать код с большой связностью (реализация высокоуровневой логики приложения) и малой связанностью (зависимость частей кода друг от друга).
Back to top
View user's profile Send private message
sv
Участник форума



Joined: 04 Jan 2004
Posts: 68
Карма: -7
   поощрить/наказать

Location: Россия

PostPosted: Fri Oct 09, 2009 10:25 am (спустя 15 минут; написано за 2 минуты 31 секунду)
   Post subject:
Reply with quote

WingedFox wrote:
Есть хорошая книжка "Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию" Шаллоуея и Тротта, она даёт правильную базу для отказа от "глубокого" наследования. Помогает начать писать код с большой связностью (реализация высокоуровневой логики приложения) и малой связанностью (зависимость частей кода друг от друга).
Благодарю.

Мои основы знаний о проектировани на php из "Профессиональное программирование на PHP. Шлосснейгл, Джордж", на php только год работаю.
Вообще я VB 6.0 и Perl программист по большей части.
Back to top
View user's profile Send private message Send e-mail
Rumata
Профессионал



Joined: 17 Aug 2003
Posts: 1850
Карма: 185
   поощрить/наказать


PostPosted: Fri Oct 09, 2009 10:55 am (спустя 29 минут; написано за 1 минуту 5 секунд)
   Post subject:
Reply with quote

sv wrote:
Вообще я VB 6.0 и Perl программист по большей части.
Какая разница какими языками Вы владеете? В данном случае речь идет о выборе методики. Как она реализована в разных я зыках - вопрос другой.
Back to top
View user's profile Send private message
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 268
   поощрить/наказать

Location: Питер

PostPosted: Fri Oct 09, 2009 11:01 am (спустя 6 минут; написано за 3 минуты 3 секунды)
   Post subject:
Reply with quote

sv
По большому счёту, знать надо не столько языки, сколько методики разработки: функциональное программирование, ООП, АОП и иже с ними.
В данном случае, я говорю про паттерны проектирования, которые живут поверх ООП, но предлагают совершенно иной подход к разработке, иной способ мышления.
Back to top
View user's profile Send private message
sv
Участник форума



Joined: 04 Jan 2004
Posts: 68
Карма: -7
   поощрить/наказать

Location: Россия

PostPosted: Fri Oct 09, 2009 11:45 am (спустя 43 минуты; написано за 48 секунд)
   Post subject:
Reply with quote

WingedFox
Rumata
Я прекрасно понимаю это.
Back to top
View user's profile Send private message Send e-mail
Maus
Модератор



Joined: 29 Jun 2003
Posts: 8151
Карма: 271
   поощрить/наказать

Location: пос. Омсукчан Магаданской области

PostPosted: Fri Oct 09, 2009 12:31 pm (спустя 46 минут; написано за 1 минуту 1 секунду)
   Post subject:
Reply with quote

я вижу только откуда делить: forum.dklab.ru/viewtopic.php?p=176076#176076 . Я не знаю:
а) как назвать;
б) не рано ли делить?
Back to top
View user's profile Send private message
dimagolov
Участник форума



Joined: 04 Feb 2007
Posts: 1664
Карма: 96
   поощрить/наказать

Location: Christ Church, Barbados

PostPosted: Fri Oct 09, 2009 6:37 pm (спустя 6 часов 6 минут; написано за 1 минуту 30 секунд)
   Post subject:
Reply with quote

Maus, a) Наследование vs паттерн Стратегия
б) по-моему вообще уже не стоит, так как sv вроде прекратил неконструктивно упираться в свое решение и начал обсуждать то, что ему советуют :)
Back to top
View user's profile Send private message
sv
Участник форума



Joined: 04 Jan 2004
Posts: 68
Карма: -7
   поощрить/наказать

Location: Россия

PostPosted: Fri Oct 09, 2009 9:46 pm (спустя 3 часа 9 минут; написано за 1 минуту 45 секунд)
   Post subject:
Reply with quote

Да согласен :), меня переубедили, но только исключительно ваши dimagolov доводы.

Можете привести пример подобной реализации?
dimagolov wrote:
но лично я отказался от подобного в пользу декораторов
Back to top
View user's profile Send private message Send e-mail
dimagolov
Участник форума



Joined: 04 Feb 2007
Posts: 1664
Карма: 96
   поощрить/наказать

Location: Christ Church, Barbados

PostPosted: Fri Oct 09, 2009 10:16 pm (спустя 29 минут; написано за 6 минут 44 секунды)
   Post subject:
Reply with quote

Ближайший пример. Мне понадобилось разбирать почтовые сообщения, получаемые в виде .eml файлов. Нашел класс Mail_mimeDecode в PEAR. Естественно мне потребовались специфические операции по анализу-преобразованию получаемых сообщений для их обработки. Варианты были унаследовать и дописать свои методы, или вставить объект класса Mail_mimeDecode в свой класс как приватное свойство и обращаться к нему по мере надобности. Выбрал второе (это и есть декоратор), оставив публичными те методы, которые нужны именно моему приложению. Кроме всего прочего, это позволило вызывать конструктор Mail_mimeDecode (весьма затратный по ресурсам, так как требует полного контента сообщения) не из конструктора, а из приватного метода Dispatch, причем не всегда, а при необходимости, который в свою очередь используется публичными методами, то есть после всех проверок корректности исходных данных.
Back to top
View user's profile Send private message
sv
Участник форума



Joined: 04 Jan 2004
Posts: 68
Карма: -7
   поощрить/наказать

Location: Россия

PostPosted: Sun Oct 11, 2009 6:51 am (спустя 1 день 8 часов 34 минуты; написано за 3 минуты 11 секунд)
   Post subject:
Reply with quote

dimagolov Благодарю!
Предельно ясно, подобным способом у меня работает валидатор входных данных формы.
dimagolov wrote:
По большому счету методы базового класса не должны использовать public или protected методов себя же, так как они могут быть переопределены и их поведение в потомках в общем случае не предсказуемо.
Этим высказыванием вы немного шокировали меня, не обращал на подобное внимания.
Потому что в больших проектах не участвовал и не натыкался на проблемы, наверное :)
Back to top
View user's profile Send private message Send e-mail
Maus
Модератор



Joined: 29 Jun 2003
Posts: 8151
Карма: 271
   поощрить/наказать

Location: пос. Омсукчан Магаданской области

PostPosted: Sun Oct 11, 2009 11:45 pm (спустя 16 часов 54 минуты; написано за 1 минуту 10 секунд)
   Post subject:
Reply with quote

dimagolov
Вопрос персонально к Вам
dimagolov wrote:
методы базового класса не должны использовать public или protected методов себя же
Откуда растут ноги у этого утверждения? Ссылку почитать, если можно.
Back to top
View user's profile Send private message
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 268
   поощрить/наказать

Location: Питер

PostPosted: Mon Oct 12, 2009 10:11 am (спустя 10 часов 26 минут; написано за 4 минуты 15 секунд)
   Post subject:
Reply with quote

dimagolov
Приведённый пример - это скорее паттерн "Фасад (en.wikipedia.org/wiki/Facade_pattern)".
Ключевая особенность - предоставление упрощённого (в т.ч. "coarse-grained") интерфейса. Используется там, где нужно скрыть часть функциональности от клиента и/или в случае наличия больших накладных расходов на вызовы методов (напр. при доступе к объекту через XML-RPC).

stackoverflow.com/questions/350404/how-do-the-proxy-decorator-adaptor-and-bridge-patterns-differ

Попробуйте найти и прочитать "Patterns Of Enterprise Application Architecture" Фаулера, будет очень и очень полезно.
Back to top
View user's profile Send private message
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 268
   поощрить/наказать

Location: Питер

PostPosted: Mon Oct 12, 2009 10:26 am (спустя 14 минут; написано за 2 минуты 55 секунд)
   Post subject:
Reply with quote

Вот, пара цитат из Блоха, подобное можно найти не только в мире жабы
Quote:
Item 16: Favor composition over inheritance
  Inheritance is a powerful way to achieve code reuse, but it is not always the best tool for the job. Used inappropriately, it leads to fragile software. It is safe to use inheritance within a package, where the subclass and the superclass implementations are under the control of the same programmers. It is also safe to use inheritance when extending classes specifically designed and documented for extension (Item 17). Inheriting from ordinary concrete classes across package boundaries, however, is dangerous. As a reminder, this book uses the word “inheritance” to mean implementation inheritance (when one class extends another). The problems discussed in this item do not apply to interface inheritance (when a class implements an interface or where one interface extends another).
  Unlike method invocation, inheritance violates encapsulation [Snyder86]. In other words, a subclass depends on the implementation details of its superclass for its proper function. The superclass’s implementation may change from release to release, and if it does, the subclass may break, even though its code has not been touched. As a consequence, a subclass must evolve in tandem with its superclass, unless the superclass’s authors have designed and documented it specifically for the purpose of being extended.
Quote:
Item 17: Design and document for inheritance or else prohibit it
  Item 16 alerted you to the dangers of subclassing a “foreign” class that was not designed and documented for inheritance. So what does it mean for a class to be
designed and documented for inheritance?
  First, the class must document precisely the effects of overriding any method. In other words, the class must document its self-use of overridable methods. For each public or protected method or constructor, the documentation must indicate which overridable methods the method or constructor invokes, in what sequence, and how the results of each invocation affect subsequent processing. (By overridable, we mean nonfinal and either public or protected.) More generally, a class must document any circumstances under which it might invoke an overridable method. For example, invocations might come from background threads or static initializers.
Так вот, паттерн "Стратегия", как раз, и является случаем "дизайна для наследования", когда оно не только разрешено, но и логично, и валидно.
Back to top
View user's profile Send private message
dimagolov
Участник форума



Joined: 04 Feb 2007
Posts: 1664
Карма: 96
   поощрить/наказать

Location: Christ Church, Barbados

PostPosted: Mon Oct 12, 2009 6:05 pm (спустя 7 часов 39 минут; написано за 3 минуты 2 секунды)
   Post subject:
Reply with quote

Maus, WingedFox меня опередил. Мое высказывание есть следствием приведенных им цитат Блоха. Может излишне категоричным, но тем не менее.

WingedFox, спасибо за ссылки и пояснения. Может быть и доберусь до Фаулера, пока больше читаю обсуждения архитектурных вопросов и делаю выводы из собственной практики. Времени на все не хватает...
Back to top
View user's profile Send private message
Maus
Модератор



Joined: 29 Jun 2003
Posts: 8151
Карма: 271
   поощрить/наказать

Location: пос. Омсукчан Магаданской области

PostPosted: Tue Oct 13, 2009 3:19 am (спустя 9 часов 13 минут; написано за 3 минуты 41 секунду)
   Post subject:
Reply with quote

dimagolov wrote:
Мое высказывание есть следствием приведенных им цитат Блоха
Увы, не вижу следования. В первом случае говорится о рисках расширения чужих классов. В обоих случаях - о необходимости документировать зависимости. Ваше утверждение с этими предметами не пересекается.
Back to top
View user's profile Send private message
dimagolov
Участник форума



Joined: 04 Feb 2007
Posts: 1664
Карма: 96
   поощрить/наказать

Location: Christ Church, Barbados

PostPosted: Tue Oct 13, 2009 6:30 pm (спустя 15 часов 10 минут; написано за 2 минуты 36 секунд)
   Post subject:
Reply with quote

использование вызовов не-приватных методов создает зависимости и как следствие, угрозу того, что класс будет поломан в будущем при наследовании. ИМХО проще не создавать зависимостей, чем документировать их и надеятся на то, что тот, кто будет модифицировать код в будущем, вычитает их в документации (даже если это буду я сам :) ).
Back to top
View user's profile Send private message
Maus
Модератор



Joined: 29 Jun 2003
Posts: 8151
Карма: 271
   поощрить/наказать

Location: пос. Омсукчан Магаданской области

PostPosted: Tue Oct 13, 2009 7:21 pm (спустя 51 минуту; написано за 5 минут 49 секунд)
   Post subject:
Reply with quote

dimagolov wrote:
использование вызовов не-приватных методов создает зависимости
при использовании класса (в декораторе или фасаде, например) Вам только и доступно, что публичные (== не-приватные) методы. Но Вас почему-то это не смущает.
dimagolov wrote:
класс будет поломан в будущем при наследовании
Класс наследованием поломать невозможно. Самое скверное, что можно сделать в потомке - это сделать несовместимую сигнатуру и изменить возвращаемый тип, но ответственность за это несет безумный создатель такого потомка. Сам класс будет жив и здоров.

Если же говорить о модификации самого класса, то в этом случае Вы не защищены ни при наследовании, ни при композиции.
Back to top
View user's profile Send private message
dimagolov
Участник форума



Joined: 04 Feb 2007
Posts: 1664
Карма: 96
   поощрить/наказать

Location: Christ Church, Barbados

PostPosted: Tue Oct 13, 2009 7:38 pm (спустя 17 минут; написано за 7 минут 16 секунд)
   Post subject:
Reply with quote

Quote:
Самое скверное, что можно сделать в потомке - это сделать несовместимую сигнатуру и изменить возвращаемый тип, но ответственность за это несет безумный создатель такого потомка.
почему же только?
Code (php): скопировать код в буфер обмена
chass A {
        public function a($x) {
                return $x + $this->b($x);
        }

        public function b ($x) {
                return $x * 2;
        }
}

class B extends A {
        public function b ($x) {
                return $x * 3;
        }
}
$oA= new A;
$oB= new B;
$x= 5;
echo (www.php.net/echo) $oA->b($x) == $oB->b($x); // false, expected
echo (www.php.net/echo) $oA->a($x) == $oB->a($x); // false, UNexpected
 
расписать как использую приватный метод получить ожидаемый результат $oA->a($x) == $oB->a($x) или и так очевидно? при сохранении публичного b(), который можно будет переопределить.
Back to top
View user's profile Send private message
Maus
Модератор



Joined: 29 Jun 2003
Posts: 8151
Карма: 271
   поощрить/наказать

Location: пос. Омсукчан Магаданской области

PostPosted: Tue Oct 13, 2009 10:13 pm (спустя 2 часа 34 минуты; написано за 1 минуту 49 секунд)
   Post subject:
Reply with quote

dimagolov
неубедительный пример - на мой взгляд, искусственная ситуация. Даже в качестве тестов такой код неприемлем
Back to top
View user's profile Send private message
Rumata
Профессионал



Joined: 17 Aug 2003
Posts: 1850
Карма: 185
   поощрить/наказать


PostPosted: Wed Oct 14, 2009 12:04 am (спустя 1 час 50 минут; написано за 5 минут 19 секунд)
   Post subject:
Reply with quote

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

Мне показалась следующая цитата в тему.
Николай Васильевич Гоголь в "Мертвых душах" wrote:
"Вишь ты, - сказал один другому, - вон какое колесо! Что ты думаешь, доедет то колесо, если б случилось, в Москву или не доедет?" - "Доедет", - отвечал другой. "А в Казань-то, я думаю, не доедет?" - "В Казань не доедет", - отвечал другой.
Back to top
View user's profile Send private message
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 268
   поощрить/наказать

Location: Питер

PostPosted: Wed Oct 14, 2009 10:04 am (спустя 10 часов 33 секунды; написано за 2 минуты 59 секунд)
   Post subject:
Reply with quote

dimagolov
Приведённый пример - это частный случай всё той же "стратегии", как она могла бы быть реализована на, например, JS или любом другом языке программирования, не реализующем область видимости "для себя и потомков".
Именно данный случай и упоминается в приведённых выше цитатах, как пример необходимости в полном документировании наследования.
Back to top
View user's profile Send private message
dimagolov
Участник форума



Joined: 04 Feb 2007
Posts: 1664
Карма: 96
   поощрить/наказать

Location: Christ Church, Barbados

PostPosted: Wed Oct 14, 2009 5:25 pm (спустя 7 часов 20 минут; написано за 6 минут 32 секунды)
   Post subject:
Reply with quote

WingedFox, ну так а я про что! Но если не задумываться об этом (а ведь обычно в момент написания класса A никто не думает о том, что кто-то захочет сделать класс B), то подобный нюанс архитектуры может быть и не отражен в документации. Более того, патерном "стратегия" пример как бы не задумывался, идея была в том, что "потом" захотели изменить поведение публичного метода b(), причем именно для публичного использования, а изменение поведения a() это нежелательное последствие хрупкости архитектуры.

Очевидным следствием потенциальной возможности подобного, является необходимость документировать не только параметры методов и их возвращаемые значения, но и их зависимости (и зависимости от них) от других методов. А раз так, то в документации раскрываются подробности реализации, для сокрытия которых и придуманы классы. И отсюда и получается мой вывод (писать код зависимым только от приватных методов), который оспаривают уважаемые Maus и Rumata.
Back to top
View user's profile Send private message
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 268
   поощрить/наказать

Location: Питер

PostPosted: Wed Oct 14, 2009 5:36 pm (спустя 10 минут; написано за 2 минуты 51 секунду)
   Post subject:
Reply with quote

dimagolov
Ну, ни разу не соглашусь, что "так надо". Архитектура должна быть продумана, но это не повод к "тотальному огораживанию".
Quote:
Item 13: Minimize the accessibility of classes and members
The single most important factor that distinguishes a well-designed module from a poorly designed one is the degree to which the module hides its internal data and other implementation details from other modules. A well-designed module hides all of its implementation details, cleanly separating its API from its implementation. Modules then communicate only through their APIs and are oblivious to each others’ inner workings. This concept, known as information hiding or encapsulation, is one of the fundamental tenets of software design [Parnas72].
Information hiding is important for many reasons, most of which stem from the fact that it decouples the modules that comprise a system, allowing them to be developed, tested, optimized, used, understood, and modified in isolation. This speeds up system development because modules can be developed in parallel. It eases the burden of maintenance because modules can be understood more quickly and debugged with little fear of harming other modules. While information hiding does not, in and of itself, cause good performance, it enables effective performance tuning: once a system is complete and profiling has determined which modules are causing performance problems (Item 55), those modules can be optimized without affecting the correctness of other modules. Information hiding increases software reuse because modules that aren’t tightly coupled often prove useful in other contexts besides the ones for which they were developed. Finally, information hiding decreases the risk in building large systems, because individual modules may prove successful even if the system does not.
Back to top
View user's profile Send private message
dimagolov
Участник форума



Joined: 04 Feb 2007
Posts: 1664
Карма: 96
   поощрить/наказать

Location: Christ Church, Barbados

PostPosted: Wed Oct 14, 2009 5:59 pm (спустя 23 минуты; написано за 4 минуты 4 секунды)
   Post subject:
Reply with quote

Quote:
Ну, ни разу не соглашусь, что "так надо". Архитектура должна быть продумана, но это не повод к "тотальному огораживанию".
Не совсем уловил как приведенная цитата опровергает то, что я написал и подтверждает процитированное высказывание. Как раз использование вызовов только приватных методов внутри методов класса скрывает реализацию и предотвращает "хрупкость" кода. Использование сторонних объектов и интерфейсов создает зависимости, по крайней мере на уровне интерфейсов, которые относительно просто контролировать, но все же зависимости.
Back to top
View user's profile Send private message
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 268
   поощрить/наказать

Location: Питер

PostPosted: Wed Oct 14, 2009 6:03 pm (спустя 3 минуты; написано за 7 секунд)
   Post subject:
Reply with quote

dimagolov
WingedFox wrote:
Архитектура должна быть продумана, но это не повод к "тотальному огораживанию".
Back to top
View user's profile Send private message
dimagolov
Участник форума



Joined: 04 Feb 2007
Posts: 1664
Карма: 96
   поощрить/наказать

Location: Christ Church, Barbados

PostPosted: Wed Oct 14, 2009 6:16 pm (спустя 13 минут; написано за 4 минуты 41 секунду)
   Post subject:
Reply with quote

WingedFox, не будите же Вы утверждать, что архитектура создается один раз и в дальнейшем не подвержена изменениям? Это звучит слишком идеализированно. А я как раз исхожу из того, что в реальной жизни она будет меняться, как по объективным, так и по субъективным причинам. Начиная от рефакторинга в процессе разработки (классный термин для сокрытия слов "ошибки разработчиков", но он имеет место быть так или иначе) и кончая появлением новых требований к системе уже после завершения разработки и необходимости модификации под эти требования.
Back to top
View user's profile Send private message
Maus
Модератор



Joined: 29 Jun 2003
Posts: 8151
Карма: 271
   поощрить/наказать

Location: пос. Омсукчан Магаданской области

PostPosted: Wed Oct 14, 2009 7:19 pm (спустя 1 час 2 минуты; написано за 9 минут 21 секунду)
   Post subject:
Reply with quote

dimagolov wrote:
но и их зависимости (и зависимости от них) от других методов
Утверждение правильно только в первой половине.

Имхо, мы тут как-то странно обсуждаем. Возможно, просто не доносим друг для друга свою точку зрения. Вернусь к началу.
Итак, для чего существуют области видимости? Для того, чтобы исключить некорректное использование класса.
Private говорит: "хотите меня вызвать - вызывайте через методы моего же класса". То есть служат для читабельности (==повышения связности) и DRY в рамках этого класса.
Protected говорит: "меня можно вызвать или переопределить в потомках, и не более".
Public говорит "я доступен для всех. Enjoy".
Методы, видимые в текущей области (строке кода, если угодно), можно использовать в любых комбинациях. Если существуют недопустимые комбинации - это ошибка проектирования.

Кстати, из вышеизложенного следует: используя только private, соблюсти DRY не получится.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic All times are GMT + 3 Hours
Page 1 of 1    Email to a Friend.
You cannot post new topics in this forum. You cannot reply to topics in this forum. You cannot edit your posts in this forum. You cannot delete your posts in this forum. You cannot vote in polls in this forum. You cannot attach files in this forum. You can download files in this forum.
XML