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]

Полностью правило звучит "... на ссылки на const", не так ли?

[voidbent.livejournal.com]

Нет. Не так. Полностью правило звучит так как я его назвал + есть отдельное правило "ставте const везде где только можно" которое я тоже не люблю. const как и любой другой механизм надо использовать не везде где только можно, а только там где он нужен.

По поводу конста - когда ты возвращаешь локальный объект по ссылке то там const пофигу.

[singalen]

Эээ, да, согласен. Но всё ещё в силе аргумент насчёт make it right.

[voidbent.livejournal.com]

Нет не в силе. Правило может приносить вред и количество этого вреда не будет коррелировать с тем какие изначальные были причины вводить это самое правило. Не важно будь то make it right или make it optimal. По крайней мере ты не доказал что количество вреда коррелирует с изначальным root cause правила.

[singalen]

Ты не доказал, что правило Composite Reuse приносит хоть какой-то вред.
Идея со ссылками была плохой, но это не значит, что ЛЮБОЕ правило, из которого бывают исключения, приносит больше вреда, чем пользы.

[voidbent.livejournal.com]

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

Кстати ещё из этой оперы правило: "используйте интерфейсы вместо абстрактных классов, где возможно"

[singalen]

Жду пример фатальной ошибки дизайна.
И в идеале - ссылку на хотя бы одну методику объектно-ориентированного анализа, если ты не веришь перечисленным источникам.

[voidbent.livejournal.com]

Фатальная ошибка дизайна в моём коменте выше - в каком-то public API сделать агрегацию квадратом фигуры думаю будет вполне фатально.
Менее фатальные ошибки - вместо наследующих друг-друга интерфейсов будут появлятся агрегирующие друг-друга классы с setter\getter-ами.

> И в идеале - ссылку на хотя бы одну методику объектно-ориентированного анализа, если ты не веришь перечисленным источникам.

Не надо "давить авторитетом". Покажи мне в этих источниках цитату в которой сказано что агрегацию надо использовать вместо наследования везде где только можно?

[singalen]

Фатальная ошибка дизайна в моём коменте выше - в каком-то public API сделать агрегацию квадратом фигуры думаю будет вполне фатально.
Ошибаешься. Во-первых, обычно квадрат является фигурой и правило нельзя применить. Во-вторых, я как-то раз заменил наследование агрегацией именно в этом случае, когда форма была всего лишь поведением. Ничего страшного не случилось, наоборот, квадрат стало легче юнит-тестировать отдельно от фигуры.

Менее фатальные ошибки - вместо наследующих друг-друга интерфейсов будут появлятся агрегирующие друг-друга классы с setter\getter-ами.
Обычно у полей для делегирования/полиморфизма вообще нет публичных аксесоров, только инициализация в конструкторе.

Не надо "давить авторитетом". Покажи мне в этих источниках цитату в которой сказано что агрегацию надо использовать вместо наследования везде где только можно?
Ты первый начал. Я изначально ссылался только на своё мнение, а потом на конкретные книги.
Java Design: Objects, UML, and Process. Ссылается на GoF.
Fine-tuning Abstraction @ Java boutique.

Собственно GoF, страница 34:"Как решать задачи проектирования" — "Наследование и композиция": "Это подводит нас ко второму правилу объектно-ориентированного проектирования: предпочитайте композицию наследованию класса. [...] С помощью делегирования композицию можно сделать столь же мощным инструментом повторного использования, сколь и наследование [Lie86, JZ91]."

[voidbent.livejournal.com]

"Это подводит нас ко второму правилу объектно-ориентированного проектирования: предпочитайте композицию наследованию класса."

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

и

"Заменяйте наследование агрегацией, где можно"

Это абсолютно разные вещи. Против правила в формулировке ГоФ я ничего против не имею.

[voidbent.livejournal.com]

Сразу поясню что-бы не возникало больше вопросов:

1. "Предпочитайте X Yу" подразумевает при прочих равных условиях.

2. "Заменяйте X на Y, где можно" подразумевает что даже если в контексте более уместным будет использование X, и в сторону использования X больше аргументов "за", но есть хоть небольшая возможность или намёк на то что-бы использовать Y - то надо использовать Y.

"Заменяйте X на Y, где можно" более сильное правило чем "Предпочитайте X Yу".

+ Я так понимаю ГоФ сперва как я уже и говорил сначала объяснили контекст "где можно", а уже потом дали правило предпочтения.

[singalen]

Ну вы, блин, даёте...

[voidbent.livejournal.com]

Проблема в самой форме "Заменяйте X на Y, где можно". Проблема, потому что не ясно "где можно".

Смотри. Обратная сторона медали. В С++ friend-ы совсем негодная технология. В этом случае правило будет звучать так: "Заменяйте friend-ы паттерном visitor везде" (или для мастеров ДАО - "... везде где вам не лень"). В этом случае visitor будет всегда предпочтительнее friend, но опять в правиле нету "..., где можно". Если-бы он там был то новички подумали бы "я не знаю что такое visitor значит в этом конкретном случае на friend его заменить нельзя. Буду использовать friend а если меня наругают, скажу что это именно тот случай когда нужен friend а не visitor". Так собственно говоря было и с макросами.

[singalen]

Если я скажу "выбирайте", а не "заменяйте", это тебя устроит?

[voidbent.livejournal.com]

Нет, не устроит :)

Во первых не надо списывать со счетов рефакторинг. Если наследование в коде "не на своём месте" и по логике вместо него должна быть агрегация, то такое наслодавние надо именно заменить агрегацией.

Во вторых смысл остался тот-же самый. Даже если по логике должно быть наследование всё равно надо будет по этому правилу выбирать агрегацию если есть хоть какая-то возможность её использовать.

В итоге "выбирайте" ещё более плохое правило чем "заменяйте"

[voidbent.livejournal.com]

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

[singalen]

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

[voidbent.livejournal.com]

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

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

[voidbent.livejournal.com]

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

[singalen]

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