OOП, немного Python и Ruby

[singalen]

Коля Голубев (nickolaygolubev) и Вова Байда (vbayba) продолжают потихоньку ковырять Python, в отличие от меня.
Оказывается, дельфин и не рыба вовсе там метод __init__ - не конструктор, а нечто, что вызывается "после коструирования" пустого объекта. Разница, как на меня, отсутствует. Тем более что только __init__ создаёт все поля класса.
Это значит, если вы хотите пронаследоваться от другого класса, нужно вызвать его __init__ из своего. А последнее значит, что конструктор вашего класса может сам выбирать, от какого класса ему наследоваться. Забавно, factory прямо в конструкторе.

Недавно думал, по какой книжке учить студентов ООП. И обнаружил, что не знаю.
Да, "Рефакторинг" содержит много хороших и вдохновляющих идей, но они там размазаны.
Буч слишком толстый, на C++, да его и не рекомендовал alf_kadett. Рекомендовал Бадда, видимо, "An Introduction to Object-Oriented Programming".
Программу по ООП отлично составил Богдан Пришедько. Он взял:

• описание АТД
• естественно, три кита - инкапсуляцию, наследование, полиморфизм... кстати, а кто выделил именно эти три? Я не нашёл;
• coupling and cohencion;
• семь приципов: Open Closed (откуда бишь это?), Liskov substitution, Dependency Inversion, Interface Segregation, Composite Reuse, Least Knowledge
• признаки "вони" кода у Фаулера;
• Рекомендации по АТД и проектироваанию классов у МакКоннелла;

Получилось хорошо.
Сергей (salpaev) сказал, что Буч действительно плох.
Рекомендовал:

• Rebecca Wirfs-Brok: "Designing Object-Oriented Software" - у неё он нашёл объяснения многим своим, как он когда-то считал, неправльным решениям - data object, stateless objects, объекты-методы и т.п. Она же критикует design patterns, например, рассматривает случаи, когда вроде бы под ситуацию неплохо подходит паттерн из GoF, а если подумать - получается совсем другой дизайн. Ну, в последний случай я не очень верю, думаю, если присмотреться, там будет либо не очень паттерновая ситуация, либо новое решение тоже окажется паттерном :)
• Лармана - "Applying UML and design patterns", только не 3е издание, а раньше. В 3м тот приплёл буззворды вроде "agile development", что не пошло книге на пользу;
• DDD - Domain-driven design Эванса, в обязательном порядке;
• Майерс "Effective C++" тоже сильно помог понять ООП, показал много новых приёмов типа двойной диспетчеризации.

Сергей же снова вернулся к скриптовым языкам и сказал, что без IDE с code completion и рефакторинга хотя бы на уровне move method порог изучения языка гораздо выше. Он бы выучил Ruby, если бы не приходилось каждый раз лазить в доку, чтобы узнать, какие методы есть в классе Array или HashTable.
И сделал вывод, что нас ждёт нашествие блондинок со знанием C#.

Comments

[singalen]

Кто это рекомендует заменять значения на ссылки? Может, всё же указатели на ссылки?
Наследование B от A можно заменять агрегацией, когда B по коду нужно только использовать функциональность A, но не быть его экземпляром.

[voidbent.livejournal.com]

Так это всего навсего определение агрегации :)

[singalen]

Именно. Удивишься, как часто кодеры разного уровня забывают этот принцип.

[voidbent.livejournal.com]

> Кто это рекомендует заменять значения на ссылки? Может, всё же указатели на ссылки?

Нет. Именно значения на ссылки. Советовал это делать Страуструп(если мне не изменяет память) мотивируя это тем что при передаче\возвращении по значению объект копируется а это требует дополнительного времени и памяти. А по ссылке передавать типа оптимально. Вот преждевременная оптимизация многих и сгубила.

[singalen]

То оптимизация, а это наоборот - упрощение дизайна. Это по пункту make it work, а не make it fast.

[voidbent.livejournal.com]

Та какая разница. Просто в общем случае для того что-бы сказать что нужно использовать агрегацию или наследование нужен архитектор. И никакие простые принципы типа "используйте агрегацию вместо наследования" тут не помогут.

[singalen]

Вот я и рассказываю, как работает архитектор :) Они же не рождаются с высшим кристально чистым пониманием системы до последнего винтика.
Правило на ВСЕ случаи жизни вывести нельзя, даже "переходя дорогу, посмотри налево", не сработает в Англии. Но ты делаешь неправильный вывод - что вообще никакими правилами пользоватья нельзя. В реальной жизни, не в математической абстракции, "правилом" можно называть высказвыание, верное в 80% случаев, ну и исключения из него тоже надо знать.

[voidbent.livejournal.com]

Я выступаю не против всех правил, а только против некоторых особо глупых :)
Плюс я выступаю не столько против правил сколько против того как они преподносятся. Меня неустраивает именно форма "заменяйте X на Y, где можно".

[singalen]

И зря. Одно неудачное правило в неудачном языке :-P - и ты уже заклеймил их все. Применяешь один случай к другому, хотя они очень разные.
Кстати, если ты читаешь правило буквально, то "где можно" не означает "везде".

[voidbent.livejournal.com]

Я уже объяснял.

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

Правило это буквально понимаю не я, а ньюкамеры которые ещё не знают "где можно" и поэтому стараются заменять везде.