Жизнь без объектов

[ermouth]

http://habrahabr.ru/post/143620/#habracut

Вскоре стало понятно, что возможность создавать повторно используемые бизнес компоненты это заблуждение. Каждый бизнес отличается от всех остальных, даже в одной отрасли. Каждый похожий проект работает по слишком специфичной бизнес логике.
Единственный способ сделать повторно используемые бизнес компоненты на этом уровне — сделать их сверх-настраиваемыми путём добавления таких штук как движки правил и встраиваемые языки. Такую модель я бы не стал называть моделью компонента. Скорее моделью очередного экземпляра bloatware”.

Паттерны не приводят к хорошей структурированности. Напротив, они приводят к чрезмерному усложнению программ, трудностям в понимании кода и дороговизне сопровождения. Некоторые паттерны стали даже анти-паттернами (например, паттерн singleton приводит к невозможности создания модульного тестирования)”.

И т.д. Полностью разделяю.

Я избегаю объектно-ориентированного подхода и сложных абстракций везде, где возможно.

Comments

[morfizm.livejournal.com]

Мне не очень понятно, что тут имеется в виду, т.к. слишком обще написано.

Но от себя могу добавить, что наследование и полиморфизм - очень опасные штуки, их можно иногда использовать, когда несколько объектов определены в одном файле (ты целиком контролируешь всю цепочку и можешь везде всё поменять), или же когда это сделано в стиле интерфейсов - абстрактный метод специально задуман для переопределения. Каждый такой метод - это + к maintenance cost и рискам несоместимости, если их использовать, то их должно быть минимальное количество.

В целом, довольно хороший reusability достигается на низких уровнях - скажем, библиотека для работы с таким-то типом storage, или структурой данных.

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

Третий вариант - бизнес компонент - это система, у которой свой жизненный цикл, deployment, etc. Если в другом бизнесе нужна похожая система, первую можно сделать чуть более универсальной, а специфику вынести в специфичные для бизнеса под-системы. API должен быть простым и крохотным. Если там всё жёстко переплетено, то может быть выгоднее сделать две монолитных системы, и дублировать код.

[grayscaler.livejournal.com]

Во-первых, что за идиотизм - переносить бизнес-объекты из одного бизнеса в другой. Как такое в голову-то пришло? Эврика, ёптыть.

Во-вторых, паттерны надо применять с умом, а не делать использование паттернов самоцелью. При умелом использовании жизнь облегчают в разы.

Так что у меня опыт противоположный - отказ от ООП всегда приводил к катастрофическому геморрою при развитии/сопровождении проекта, а также при смене разработчика.