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

[nponeccop.livejournal.com]

http://en.wikipedia.org/wiki/Open/closed_principle

Вы пробовали реализовывать Open/Closed на практике? Мне кажется, это будет сплошной Copy/Paste и overengineering.

[singalen]

Обычно мне хватало здравого смысла этого не делать.
Мне кажется, он применим, но довольно редко: когда мы делаем API для специфического случая.
Хотя, он противоречит принципу "заменяйте наследование агрегацией, где можно". Обычно я таки-предпочитаю давать интерфейс (open по определению) как callback клиентскому коду, и агрегировать его в свой полностью closed класс.
Хотя, да, я делал классы, в которых наследники могли и должны были переопределить один или два метода. И да, это иногда приводит к copy-paste - когда в наследнике нужно выполнить только ЧАСТЬ или вариацию на тему функциональности предка. А overengineering-а не замечал, наоборот, чтобы вынести переопределяемый метод в отдельный интерфейс, придётся вводить этот самый интерфейс - новую сущность.

Про "заменяйте наследование агрегацией" в учебном курсе тоже было :)

[catty-ua.livejournal.com]

>>без IDE с code completion и рефакторинга хотя бы на уровне move method порог изучения языка гораздо выше - 100 % . Всё, что я знаю сейчас - благодаря тому, что когда-то на первой у работе меня был оочень тормознючий комп, и подсказки и code completion пришлось нафик отключить. Многое подсознательно запомнилось, потому что лень было каждый раз лазить в хелп...

З. Ы. >> что нас ждёт нашествие блондинок со знанием C# - бу-го-га, дык... я - первая ласточка ? :-D

[singalen]

Всё запоминается, так или иначе.
Определённо :-]]]

[singalen]

Это "Composite reuse", естественно.

[alf-kadett.livejournal.com]

Именно его, Бадд хороший. С примерами на Objective C, C++, Java, Smalltalk.

[its-probably-me.livejournal.com]

Под Руби уже есть пара плагинов к Эклипсу и Нетбинсам, плюс платная IDEA и еще что-то. Ну и Borland/CodeGear обещают что-то летом выкатить.

[holmic.livejournal.com]

[voidbent.livejournal.com]

Не люблю я эти принципы "заменяйте X на Y, где можно". Вспомни только огромную толпу кор, которые своё начало берут в принципе "В С++ заменяйте передачу по значению на ссылки, где можно". В подобных утверждениях проблема во фразе "..., где можно". А где можно? Попробуй сформулировать 1-м предложением где можно заменять наследование на агрегацию а где нельзя? Естественно не понимая "где можно" и даже не пытаясь этого понять передачу по значению начали заменять на ссылки везде, в том числе возвращая локальный объект из функции и т.д.

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

[singalen]

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

[singalen]

Как раз "первобытные архитекторы" обожали наследование. Как же, это же полиморфизм!

[voidbent.livejournal.com]

Значит "заменяйте наследование агрегацией" придумали уже в средние века :) Заблуждались и те и те :)

[voidbent.livejournal.com]

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

[singalen]

Я дал ответ и до сих пор в него верю. Пока проблем не было.
Если правило ремесла работает в 95% случаев, это уже очень хорошее правило (сравни с open-closed). В 5% срабатывает оговорка "...если это не потребует ввести одну-две лишние сущности", ну так одним правилом никакой приём ремесла и не описывается.

[voidbent.livejournal.com]

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

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

[singalen]

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

[voidbent.livejournal.com]

Правило "В С++ заменяйте передачу по значению на ссылки, где можно" работает в 95% процентах случаев но это очень-очень-очень плохое правило. Во первых потому что в 5% случаев это правило приводит к краху системы; а во вторых потому что оно приводит к атрофии того участка мозга который должен отслеживать эти 5% случаев.

[singalen]

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

[voidbent.livejournal.com]

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

[singalen]

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

[voidbent.livejournal.com]

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

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

[singalen]

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

[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% случаях приводит к фатальным ошибкам (в случае со ссылками это были фатальные ошибки работы с памятью а в этом случае это будут фатальные ошибки дизайна. Научив молодых этому правилу ты задолбёшся после них код рефакторить убирая агрегацию квадратом фигуры). Это происходит из за того, что решения относительно агрегации и наследования должны приниматься на основании объектно-ориентированного анализа, а не на основании правила которое говорит что агрегацию нужно применять везде где только можно.

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

[voidbent.livejournal.com]

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

[singalen]

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

[singalen]

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

[voidbent.livejournal.com]

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

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

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

[voidbent.livejournal.com]

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

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

[voidbent.livejournal.com]

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

[aleksijb.livejournal.com]

Ставя себя на место студентов. Мне бы например подошло все что связано с решением конкретных задач, пусть даже упрощенных. Например такое:
Fowler Analysis patterns
GOF Пример в начале
Дизайн хороших библиотек, например HotDraw
ИМХО человек должен полюбить процесс создания дизайна, после такой зацепки дальше сам разберется.

[aleksijb.livejournal.com]

Еще один взгляд на ОО дизайн:

http://ru.smalltalk.wikia.com/wiki/ПРИНЦИПЫ_ОО_ДИЗАЙНА

[voidbent.livejournal.com]

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

[singalen]

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

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

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

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

[singalen]

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

[singalen]

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

[voidbent.livejournal.com]

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

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

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

[voidbent.livejournal.com]

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

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

и

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

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

[voidbent.livejournal.com]

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

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

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

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

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

[singalen]

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

[singalen]

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

[voidbent.livejournal.com]

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

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

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

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

[voidbent.livejournal.com]

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

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

Посоветуйте сайт с музыкой для начинающего рэппера

[(Anonymous)]

Здравствуйте.

Я - начинающий брейкдансер. Хочу посмотреть новые элементы брейкданса.

Где и как это можно сделать, цена?

[singalen]

Какие оригинальные боты пошли.