Здравствуйте, IT, Вы писали:

G>>А что ты предлагаешь вместо ООП? Функциональный подход? Или ещё какие-то парадигмы, более успешные в решении обсуждаемой проблемы?

IT>Ты требуешь универсального решения всех проблем? У меня такого нет

G>>Ясно. Ну с твоей точки зрения выходит, что любая методология будет иметь проблемы. Но ведь наличие проблем — это часть диалектической природы, от таких проблем нельзя уйти.

IT>Любая методология, инструмент, паттерн, парадигма, принцип всегда привносит усложение в любое решение. Это аксиома. Вопрос лишь в том, будет ли и на сколько выигрышь превышать затраты.

Я уверен, что соблюдение SOLID, паттернов, элементов DDD, контрактное программирование, проверка инвариантов, практики Clean code дают выигрыш в затратах на сопровождение кода — т.к. багов меньше, код — надежнее. Кроме того, некоторые принципы, типа OCP, кроме прочих бенефитов снижают и кол-во регрессионных багов. Да и писать такой код проще, т.к. есть четкие правила, и ты не гоняешь "а как сделать? как назвать переменную? как спроектировать иерархию? писать или не писать проверку инвариантов? если писать, то полную или не полную? а писать ли тесты?", а следуешь этим правилам, указанным в обще-командном чек-листе и не паришся, как осел перед двумя идентичными стогами сена, а просто пишешь код. Также повышается уверенность в качестве кода и снижается страх перед неопределенностью — а взлетит или не взлетит? Если повезет и взлетит, достаточно ли хорошо и полно написан код?

G>>Или все же есть нечто более адекватное, чем ООП?

IT>Да причём здесь ООП. Давай без ООП и вообще без программирования.

IT>Например, возьмём проблему превышения скорости транспортными средствами в жилых районах. В соответствии с принципом Лисковой нужно в каждый двор поставить по полицейскому (ревьюверу), который будет отлавливать нерадивых Вась Петиных. А можно решить проблему другим способом — положить лежачих полицейских и никаких стоячих ревьюверов тогда не понадобится.

Ясно, ну на такой случай у нас в чек-листе есть правило — не заниматься оверинжинирингом. Не лепить везде OCP полиморфизм вместо условий, т.к. это не всегда нужно. Не оптимизировать раньше времени. И т.д.
SOLID ради SOLID — это тоже известная проблема, и те кто их практикует не дураки, не лепят их везде и всюду. Если есть компромисс, то идут на компромисс. SOLID применяется когда необходимость действительно назревает, т.е. делается рефакторинг. Единственное, что важно — это наличие тестов, которые защитят отрефакторенный код от регрессии.
Ну и прицнип KISS есть, хотя он не такой простой в реализации, как в формулировке. Делать просто — это сложная задача.

Здравствуйте, IT, Вы писали:

G>>А что ты предлагаешь вместо ООП? Функциональный подход? Или ещё какие-то парадигмы, более успешные в решении обсуждаемой проблемы?

IT>Ты требуешь универсального решения всех проблем? У меня такого нет

G>>Ясно. Ну с твоей точки зрения выходит, что любая методология будет иметь проблемы. Но ведь наличие проблем — это часть диалектической природы, от таких проблем нельзя уйти.

IT>Любая методология, инструмент, паттерн, парадигма, принцип всегда привносит усложение в любое решение. Это аксиома. Вопрос лишь в том, будет ли и на сколько выигрышь превышать затраты.

Я уверен, что соблюдение SOLID, паттернов, элементов DDD, контрактное программирование, проверка инвариантов, практики Clean code дают выигрыш в затратах на сопровождение кода — т.к. багов меньше, код — надежнее. Кроме того, некоторые принципы, типа OCP, кроме прочих бенефитов снижают и кол-во регрессионных багов. Да и писать такой код проще, т.к. есть четкие правила, и ты не гоняешь "а как сделать? как назвать переменную? как спроектировать иерархию? писать или не писать проверку инвариантов? если писать, то полную или не полную? а писать ли тесты?", а следуешь этим правилам, указанным в обще-командном чек-листе и не паришся, как осел перед двумя идентичными стогами сена, а просто пишешь код. Также повышается уверенность в качестве кода и снижается страх перед неопределенностью — а взлетит или не взлетит? Если повезет и взлетит, достаточно ли хорошо и полно написан код?

G>>Или все же есть нечто более адекватное, чем ООП?

IT>Да причём здесь ООП. Давай без ООП и вообще без программирования.

IT>Например, возьмём проблему превышения скорости транспортными средствами в жилых районах. В соответствии с принципом Лисковой нужно в каждый двор поставить по полицейскому (ревьюверу), который будет отлавливать нерадивых Вась Петиных. А можно решить проблему другим способом — положить лежачих полицейских и никаких стоячих ревьюверов тогда не понадобится.

Ясно, ну на такой случай у нас в чек-листе есть правило — не заниматься оверинжинирингом. Не лепить везде OCP полиморфизм вместо условий, т.к. это не всегда нужно. Не оптимизировать раньше времени. И т.д.
SOLID ради SOLID — это тоже известная проблема, и те кто их практикует не дураки, не лепят их везде и всюду. Если есть компромисс, то идут на компромисс. SOLID применяется когда необходимость действительно назревает, т.е. делается рефакторинг. Единственное, что важно — это наличие тестов, которые защитят отрефакторенный код от регрессии, и с этим иногда беда и бывает.
Ну и прицнип KISS есть, хотя он не такой простой в реализации, как в формулировке. Делать просто — это сложная задача.