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

[voidbent.livejournal.com]

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

[singalen]

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

[voidbent.livejournal.com]

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

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

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