Оver-engineering - "зачем так сложно?" - Мортира Карл

[Raven Melancholic]

Цитата:

контрагент.Действие() vs действие(Контрагент) это принципиальный подход.

Действительно принципиальный, вопрос в том, выбор одного из двух (трех, четырех, пяти ...) это абсолют или должно быть привязано к текущей задачи, к будущим задачам, к тому что знаем сейчас и к тому, что узнаем позже, можем ли при большем узнавании ситуации менять подход, сколько нам будет стоить это изменение, ну и всякие разности, связанные со словами Концепция и Архитектура.
Простой пример: Кот.Погладить, Погладить(Кот). Пока отвлечемся от русского языка и под погладить будем иметь ввиду не провести горячим утюгом, а нежно ладошкой провести от начала макушки до шеи.
Действие одно, а вот последствия разные и их бы нужно предусмотреть перед тем как выполнить это действие:

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

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

[ax_mct]

Цитата:

Сообщение от Raven Melancholic

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

Именно что инструментарий.

Кому будет легче если сделать из одного метода settleNow() отдельный фрэймворк из пары десятков классов, документацию к нему по его API, затем патентовать костыли чтобы вызывать нужный класс.

Да, можно сделать так чтобы это разбиение было интуитивно и обоснованно, но мало кто так может, будут нормализовывать код до размазни и думать об абстрактной красоте, а не о практичности использования. Поэтому пусть эти 2000 строк там и останутся.

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