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]

Я уже сказал что основная проблема таких правил в том что они учат молодых следовать правилам вместо того что-бы думать. В итоге после такого обучения мы получаем толпы бездумных "имплементеров".

[singalen]

Покалеченные обучением "имплементеры" - твои домыслы. Если они были бездумными изначально, то пусть лучше следуют правилам, чем поступают по своему разумению, а если умели думать, то не разучатся.

[voidbent.livejournal.com]

Да? Странно.
А у меня на собеседованиях каждый первый кто знает что такое ссылка возвращает в operator+()-е ссылку на локальный объект.
А те кто собеседование всё-таки проходят в бейс курсе в operator+()-е возвращают ссылку уже не на локальный объект а на объект из статического пула.

И это проблема создана именно образованием.

[voidbent.livejournal.com]

В том то и проблема что они не бездумны изначально. Бездумными их делает тупое образование+тупые книжки+тупые курсы

[singalen]

Гу-гу-гу. GOF.
Ты немного поторопился с выводами насчёт качества этого правила.