?

Log in

No account? Create an account
   Journal    Friends    Archive    Profile    Memories
 

ООП - morfizm


Mar. 13th, 2013 02:17 am ООП

http://avva.livejournal.com/2581700.html
Хороший пост, я бы по сути примерно то же самое сказал, но не так хорошо как Анатолий :)

Мой опыт за последние 7-8 лет подтверждает основные пункты:
• ООП это круто главным образом как инструмент для модуляризации.
• Инкапсуляция это круто.
• Наследование интерфейсов это круто. (Наследование от абстрактного класса, или полиформизм над абстрактными функциями, как реализация интерфейса).
• Наследование кода это не круто, ведёт к багам и тяжело сопровождать. Основная проблема – программист, глядящий в потомка, должен мочь полностью абстрагироваться от предка, а, на самом деле, не может, и вынужден делать какие-то предположения о том, как предок работает. Эти предположения часто не правильны.
• Множественное наследование это ужасно, ведёт к тяжёлым багам.

Добавлю ещё от себя, что:
• Агрегация (где возможно и уместно) зачастую лучше наследования. Легче тестировать, лучше модульность.
• Один параметризованный класс-предок лучше иерархии с кучей классов, наследующих и немножко меняющих предка.
• Нужно иметь опыт, чтобы получать бенефиты от ООП. Скажем, проблемы от overuse ООП (куча ненужных wrapper’ов, уровней абстракции и др.overengineering’а) зачастую более серьёзны (wrong assumptions, abstraction leaks, complexity), чем сложности от сопровождения если тупо фигачить модули в сишном стиле. Другими словами, неопытный программист, хорошо знающий ООП, более опасен, чем неопытный программист, его не знающий. По-моему, ООП это очень важно и нужно, но я бы, наверное, не был против если бы стоял вопрос о том, чтобы не давать его на первом курсе.

Темплейты это тоже некруто. Они убивают читаемость, особенно при отладке, и это сводит на нет плюсы от недублирования кода. Кроме того, за исключением очень редких случаев каких-то хардкорных библиотек (скажем, самое ядро движка сложной 3D игры), реальные задачи не требуют универсальности типов данных и пр. Матрица тестирования всё равно сильно увеличивается, и создаётся кажущаяся иллюзия, будто бы её можно не увеличивать, отсюда новые баги.

Tags:

21 comments - Leave a commentPrevious Entry Share Next Entry

Comments:

From:balmerdx
Date:March 13th, 2013 02:52 pm (UTC)
(Link)
"Кроме того, за исключением очень редких случаев каких-то хардкорных библиотек (скажем, самое ядро движка сложной 3D игры), реальные задачи не требуют универсальности типов данных и пр."

3D движок и темплейты - это вещи почти несовместимые. То есть конечно можно использовать их в каком нибудь ненужном и неважном месте 3D движка, но не более того.
From:yau_hen
Date:March 13th, 2013 03:25 pm (UTC)
(Link)
Мне тоже хочется сделать заявление.
Темплейты по производительности ничем не хуже макросов. Поэтому вполне применимы в самых критических по производительности местах.
From:morfizm
Date:March 13th, 2013 04:35 pm (UTC)
(Link)
Я же не спорю по поводу критических по производительности мест. Только 99% кода такими местами не являются, а защитники темплейтов любят пихать их везде просто для красоты или для того, чтобы избежать какое-то дублирование, или чтобы сделать что-то универсальным, когда нигде не требуется такая универсальность. Это тянет все недостатки темплейтов, не компенсируя достоинствами.
From:yau_hen
Date:March 13th, 2013 06:59 pm (UTC)
(Link)
Так и ответ мой был не на твой пост, а на заявление balmerdx. :)
Я у темплейтов нахожу только один существенный недостаток - это то что контракт ожидаемый темплейтом от типа T явно не прописывается и соответственно компилятором никак не проверяется. Были попытки включить концепты в недавний стандарт - но что то не срослось.
From:morfizm
Date:March 13th, 2013 05:44 pm (UTC)
(Link)
Ходят слухи, что Степанов сказал, что если бы он знал, как STL будет реально использоваться, то никогда бы не создал его.
From:balmerdx
Date:March 13th, 2013 07:01 pm (UTC)
(Link)
STL неплох, в той части которая vector, map, string. Но на других языках значительно более приятные базовые библиотеки. Это я про C#, Java, Python.

Воот Буст ужасен. Если что и убъет C++, так это Буст.
From:morfizm
Date:March 16th, 2013 04:52 am (UTC)
(Link)
STL неплох, когда используют несложные комбинации из vector/map/string. Он плох, начиная с использования итераторов. Буст ужасен. Но ещё ужаснее home-grown template classes, особенно используемые в комбинации с STL и boost.


Edited at 2013-03-16 04:57 am (UTC)
From:balmerdx
Date:March 13th, 2013 07:04 pm (UTC)
(Link)
Дык никто не спорит, темплейты вполне неплохи для метапрограммирования. Если их использовать чуть-чуть. Но вот когда используются сложные конструкции и высокая темплейтная магия - становится грустно. Скажем в Бусте почти везде темплейты зазря использованны. Впрочем Буст это мой любимый пример как не нужно писать библиотеки.
From:morfizm
Date:March 13th, 2013 04:32 pm (UTC)
(Link)
Я когда-то спорил о ненужности темплейтов с несколькими людьми в кружочках, среди которых было пару гейм девелоперов, и мои аргументы не работали именно для них, т.к. у них оправданный use case, где нужно писать что-то очень сложное и оптимизированное для разных типов данных, и риск расплодить баги перевешивает сложности поддержки, а использовать меньше типов нельзя по причинам микро-оптимизации производительности. Пожалуй, кроме 3D движков я могу назвать ещё ядро операционки и high frequency trading. Это use cases это капля в море на фоне всего многообразия девелопмента в софтварной индустрии.
From:balmerdx
Date:March 13th, 2013 06:55 pm (UTC)
(Link)
Ядро операционки без вариантов пишут на С без плюсов. Темплейты в 3D в тему видал в местах, аналогичных stl, свои специализированные массивы и деревья, не более того.

Кстати сейчас пишу дома для микроконтроллеров на C и отлично понимаю почему ядро операционки пишут именно на этом языке.
From:yau_hen
Date:March 13th, 2013 03:29 pm (UTC)
(Link)
"Темплейты это тоже некруто" vs "Один параметризованный класс-предок лучше" что побеждает?
From:morfizm
Date:March 13th, 2013 04:37 pm (UTC)
(Link)
Параметризовать класс можно и динамически. Инициализировать другие значения в полях.

Ещё больше побеждает просто один класс. Из моего опыта программисты часто добавляют ненужную универсальность там, где можно легко обойтись без неё, и с втрое меньшим количеством кода.
From:yau_hen
Date:March 13th, 2013 06:44 pm (UTC)
(Link)
Используй правильную терминологию. :)
From:morfizm
Date:March 16th, 2013 04:56 am (UTC)
(Link)
Помоги выбрать более правильную.
Предлагаешь слово "параметризовать" взять в кавычки, чтобы отличать от темплейтной параметризации?
From:yau_hen
Date:March 13th, 2013 03:39 pm (UTC)
(Link)
У меня как раз опыт с ООП сильно замедлился 7 лет назад.
"плюсы от недублирования кода" - это всё то что видят в ООП подавляющее большинство программистов по моему опыту (не принимай на свой счет). В базовый класс или темплейт тупо выносят общую на данный момент функциональность. Момент уходит и появляются проблемы типа нечитаемости, бажности, несопровождаемости и т.д.
From:morfizm
Date:March 13th, 2013 04:39 pm (UTC)
(Link)
Согласен.

Кстати, ты натолкнул на аналогичное наблюдение. Способность выборочно/вдумчиво/понимая последствия дублировать код это какое-то свойство опытного программиста. Новички имеют тенденцию злоупотреблять, пытаясмь избежать дублирования любой ценой, и это плохо заканчивается.
From:yau_hen
Date:March 13th, 2013 06:48 pm (UTC)
(Link)
"выборочно/вдумчиво/понимая последствия дублировать код" - это все входит в умение "выделять абстракции" подходящие для задачи. Да, приходит с опытом.
From:balmerdx
Date:March 13th, 2013 07:08 pm (UTC)
(Link)
Я сейчас как раз на наблюдаю за этим процессом. Дали новичку у нас в фирме написать враппер движка для DirectX под Windows Phone 7, с одной стороны он написал много лишнего кода. С другой стороны пытался вынести в общий код буквально по 2-3 строки текста, приходилось объяснять почему не надо так делать.
From:me_milady
Date:March 13th, 2013 09:50 pm (UTC)
(Link)
Что бы такое почитать/поделать чтобы ООП прочувствовать в полной мере? У нас же вроде тоже ООП, но в такой мере как ты здесь написал - у меня не прочувствовано.
From:archaicos
Date:March 16th, 2013 03:27 am (UTC)
(Link)
Есть классические книги по ООП:

Object-Oriented Analysis and Design with Applications

Design Patterns: Elements of Reusable Object-Oriented Software

Лучше всего ООП видно и обосновано во всяких GUI и CAD системах. Там без него в чём-то мало-мальски сложном можно просто вешаться. В других местах не всё так чётко. В любом случае, надо думать и понимать, где ООП - хорошо, а где - нет, в частности когда ООП навязывается ради самого ООП, и вместо помощи в решении проблем создаёт больше новых проблем.

Часто бывает так, что человек прочитывает книгу про ООП и воодушевлённо начинает его везде совать. Это как с преждевременной оптимизацией, когда оптимизируется не то, и усложняет работу когда дело доходит до оптимизации того, что надо, или при расширении функциональности и приходится сильно менять структуру кода, APIs и т.д.
From:morfizm
Date:March 16th, 2013 04:34 am (UTC)
(Link)
Попробуй сделать такое упражнение. Напиши скрипт, который найдёт в твоём проекте файлы, имеющие PHP и HTML вперемешку. Т.е. которые имеют <?php более одного раза, или же один раз но не в самом начале. Выбери 5 самых важных и частоиспользуемых и перепиши их, вынеся функциональность в библиотечный класс и отдельно темплейт с HTML-ом. Будет и приятно, и полезно. Лучше прочувствуешь.

Edited at 2013-03-16 04:34 am (UTC)