Сказ об ООП, пиве, чае и дружбе

[IvanSTV]

спасибо, пользительно весьма оказалась. Меня лично подвигло почитать кое-что о зависимости и наследовании в VBA - просто стало интересно, пользуется ли этим кто или нет. Выяснил- там все через одно место, и понимают как этим пользоваться, единицы.

[eandr_67]

Это всё — про то, как оформить код. Но до того, как заниматься написанием кода, надо сначала найти способ достижения заданной цели (т.е. алгоритм, который этот код будет реализовывать). И если великолепно оформленный — по всем заветам ООП — код, обрабатывающий большой массив данных, имеет вычислительную сложность O(n³) при наличии общеизвестного алгоритма O(n∙log(n)) — это безусловный говнокод, демонстрирующий умение писать код при абсолютном незнании элементарных основ программирования.

Наследование — зло, порождающее хрупкий код. Оно создаёт больше проблем, чем решает. Намного надежнее использовать только интерфейсы — вообще без наследования. Типажи (trait) + интерфейсы обеспечивают в точности те же возможности, но без присущих наследованию проблем. Более того, вскользь упомянутая в статье композиция также является полной и куда более надёжной заменой наследованию.

Мантра «полиморфизм, инкапсуляция, наследование» — это не «киты ООП», а всего лишь наиболее модный из вариантов компонентного программирования (включающего множество разных вариантов ООП). Тот же Go великолепно обходится и без наследования, и даже без классов. И даже JavaScript много лет прекрасно жил без классов — пока корпорации, заведующие стандартизацией JS, не решили удешевить подготовку JS-разработчиков.

[Tuki_Tip]

Алгоритмы, это очень важная состовляющая ПО. Плохой алгоритм не компенсирует ни одна хорошая архитектура и дизайн кода. Но справедливо и обратное. Если код плохо оформлен, не правильно спроектирован, имеет высокую связность и т.д. его трудно будет изменять. Если код трудно изменять, значит новые требования будут реализовываться дольше и поддержка такого продукта будет неумолимо увеличиваться. Соответственно, будет сложно успеть за рынком.

Поэтому, считаю, что не нужно алгоритмы противопостовлять архитектуре. Они одинаково важны и задача разработчика удержать баланс этих состовляющих. В зависимости от специфики и нефункциональных требований приложения, чаша весов может отклонятся в сторону алгоритмов или архитектуры.

[mafia8]

Правило №1 при объяснении ООП: Не использовать код.

[Akela_wolf]

Начнем с того, что в данной статье рассматривается единственный способ писать код - объектно-ориентированное программирование. Но это не является серебряной пулей, как минимум не рассмотрено функциональное программирование. Не рассмотрен процесс превращения "реального" в "виртуальное" как процесс построения некоей модели.

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

[VXP]

Благодарю) Очень полезно, как по мне