Я считаю, что главный метапринцип, который должен лежать в проектировании любой архитектуры — это управляемость данной архитектуры. Этому принципу уже подчинены все остальные методологии, типа KISS, DRY, SOLID; шаблоны проектирования и т.д.
Если приложение небольшое и за использованием копипасты можно следить (управлять, контролировать) — копипаста это отличное решение. Это экономит время и средства. Но это не ваш случай, похоже, хотя именно его и реализовали)
Основная проблема примера в том, что все то, что должно находиться в одном месте у вас разносится по разным классам. В данном случае — это метод изменения статуса посылки. Эта проблема не разрешима в рамках 2х представленных классов. А значит она должна быть разрешена ВНЕ классов Parcel и UrgentParcel. Достаточно создать отдельный (статический или обычный, двойная диспетчеризация как у визитора или просто вызов нужного метода — это дело вашего вкуса) класс, который будет отвечать за реализацию всех методов изменения статусов у всех типов отправлений. В итоге получаем, что весь код для изменения статусов находится в одном месте:
Алгоритмы работы методов для класса легко «просматриваемые»
Копипаст убирается отдельными реализациями различных закрытых методов внутри класса-стратегии
Принцип SPR прекрасно реализован)
У любой программной системы есть внешние ограничения, которые являются первичными по отношению к ней. Например, это требования бизнес-процессов, которые накладываются на неё. Также, у любой архитектуры есть внутренние рамки, в которых она может меняться — именно для этих рамок действуют все методологии и в частности принципы SOLID. Если в систему приходят внешние требования, которые не укладываются в возможности текущей архитектуры, то у нас два выхода — либо костыли (наше все), либо частичное перепроектирование архитектуры (недостижимая мечта). Когда мы выбираем второе, то на момент проектирования некоторые принципы SOLID из старой системы не действуют в новой — нам приходится менять базовые классы, их поведение и т.д. Чаще всего нарушается принцип Open-Closed.
В частности, студенческое решение вида — «а добавим мы к базовому классу поле bool IsUrgent {get; set;}» является частичным перепроектированием архитектуры, на который принцип Open-Closed не распространяется. Нужно ли оно или нет, правильное — или нет — это все зависит от того, как, где и зачем эксплуатируется система, кто её поддерживает и т.д.
Со стороны складывается впечатление, что вы пытаетесь забивать гвозди экскаватором. Языки развившиеся естественным путем несут в себе семантическую неоднозначность, исходя из самой концепции их построения — слова в них, это всегда кодировка определенных образов, которая дает возможность толковать практически любую информацию с разными контекстами. Чтобы это преодолеть, необходимо выработать иную концепцию языка\схем представления данных\etc.., в которой будут кодироваться только четкие и однозначные понятия. Однако, не все в нашем мире можно описать «абсолютно точно» и «с вероятностью 13,333(3)%».
И мифологическое сознание тут совершенно не причем.
«ИТ-аутсорсинг — крупный игрок в индустрии высоких технологий.» (с) ICL Services
Я то думал, что ИТ-аутсорсинг — это передача определённых функций ИТ-отдела в другие компании, а это оказывается игрок…
Если приложение небольшое и за использованием копипасты можно следить (управлять, контролировать) — копипаста это отличное решение. Это экономит время и средства. Но это не ваш случай, похоже, хотя именно его и реализовали)
Основная проблема примера в том, что все то, что должно находиться в одном месте у вас разносится по разным классам. В данном случае — это метод изменения статуса посылки. Эта проблема не разрешима в рамках 2х представленных классов. А значит она должна быть разрешена ВНЕ классов Parcel и UrgentParcel. Достаточно создать отдельный (статический или обычный, двойная диспетчеризация как у визитора или просто вызов нужного метода — это дело вашего вкуса) класс, который будет отвечать за реализацию всех методов изменения статусов у всех типов отправлений. В итоге получаем, что весь код для изменения статусов находится в одном месте:
У любой программной системы есть внешние ограничения, которые являются первичными по отношению к ней. Например, это требования бизнес-процессов, которые накладываются на неё. Также, у любой архитектуры есть внутренние рамки, в которых она может меняться — именно для этих рамок действуют все методологии и в частности принципы SOLID. Если в систему приходят внешние требования, которые не укладываются в возможности текущей архитектуры, то у нас два выхода — либо костыли (наше все), либо частичное перепроектирование архитектуры (недостижимая мечта). Когда мы выбираем второе, то на момент проектирования некоторые принципы SOLID из старой системы не действуют в новой — нам приходится менять базовые классы, их поведение и т.д. Чаще всего нарушается принцип Open-Closed.
В частности, студенческое решение вида — «а добавим мы к базовому классу поле bool IsUrgent {get; set;}» является частичным перепроектированием архитектуры, на который принцип Open-Closed не распространяется. Нужно ли оно или нет, правильное — или нет — это все зависит от того, как, где и зачем эксплуатируется система, кто её поддерживает и т.д.
И мифологическое сознание тут совершенно не причем.
Вот тут неплохая статья эту тему: https://habrahabr.ru/company/oleg-bunin/blog/313364/
Я то думал, что ИТ-аутсорсинг — это передача определённых функций ИТ-отдела в другие компании, а это оказывается игрок…