Это довольно старый вопрос, ответ на который уже был принят, но чтобы уточнить предоставленный ответ и ответить на вопросы, возникшие в разделе комментариев, предоставляется этот дополнительный ответ.
В том виде, в каком он поставлен, вопрос несколько неопределенный. Когда спрашивают, следует ли что-то делать определенным образом в отношении разработки программного обеспечения, этот вопрос можно понять как вопрос, касающийся основных принципов проектирования, которые регулируют рассматриваемую тему, когда такие принципы проектирования следует применять, если не единообразно, или и то, и другое. . Чтобы помочь в объективном обсуждении темы, давайте рассмотрим эти два аспекта по очереди.
Конкретная практика создания конструктора для сопоставления значений одного объекта с другим создает связь между двумя объектами. Модель представления содержит свойства и / или поведение, относящиеся к конкретному представлению в системе. Поскольку целью такого объекта является моделирование определенного представления, инкапсуляция логики сопоставления для инициализации внутреннего состояния / значений модели из другого типа в системе означает, что модель представления теперь содержит код, который может потребоваться изменить по причинам. кроме изменений в способе моделирования представления. Такие изменения открывают возможность неблагоприятного воздействия на другие аспекты поведения модели, вызывая тем самым непреднамеренный регресс в поведении системы. Принцип, регулирующий разделение компонентов внутри системы для предотвращения непреднамеренного регресса поведения за счет объединения нескольких проблем, называется принципом единой ответственности.
Вопрос о том, когда следует применять такие принципы, немного сложнее. Важно помнить, что программное обеспечение обычно пишется с определенной целью (например, решение некоторых бизнес-задач, содействие развлечению или обучению и т. Д.), И то, что лучше всего для любой конкретной части программного обеспечения, зависит от поставленной задачи. Выбор программной системы, которая создается в качестве флагманского продукта для конкретной компании, может сильно отличаться от выбора системы, разрабатываемой для решения неотложной проблемы. Также необходимо учитывать объем работ, необходимых для облегчения определенных типов развязки. Некоторые методы развязки относительно легко внедрить, в то время как другие могут быть более сложными и даже включать пошаговые кривые обучения для начальной реализации, а также для каждого нового разработчика, добавляемого в команду, ответственную за обслуживание программного обеспечения. Хотя никакая эвристика не является идеальной для принятия таких решений, разработка через тестирование предлагает эвристику не вводить абстракции до тех пор, пока не появится дублирование. Например, шаблон стратегии - отличный метод соблюдения принципа открытости / закрытости, принципа, регулирующего проектирование объектов, позволяющее применять их в различных сценариях без необходимости изменять существующий код. Однако, следуя практике разработки через тестирование, нельзя вводить шаблон стратегии, пока не будет обнаружен второй вариант использования. Следуя этой эвристике, разработчики вынуждены ограничивать свои усилия выполняемой задачей, написав только код, необходимый для выполнения задачи без дублирования, что приводит к минимизации потерь и максимизации ремонтопригодности (посредством минимизации сложности).
Тем не менее программная инженерия - это одновременно наука и искусство. Это наука в том смысле, что существуют правила, которые регулируют, что можно и что нельзя делать для достижения определенных целей, но это также искусство в том смысле, что чем больше вы это делаете, тем лучше вы становитесь, и нужно идти на определенные компромиссы. что в конечном итоге должно быть сделано субъективно. Например, как разработчик клиентского программного обеспечения я обычно никогда не участвую в проектировании и разработке приложений с коротким сроком службы. Таким образом, я не жду, пока увижу дублирование, прежде чем вводить в свои приложения внедрение зависимостей на основе соглашений. Внедрение последовательного использования внедрения зависимостей в приложении обходится гораздо дешевле в начале жизни программной системы, чем ожидание, пока вы не почувствуете в этом потребность.
Что касается конкретного примера добавления кода сопоставления в модели представления, хотя он действительно связывает модель представления с конкретной моделью предметной области, на практике я не считаю это большой проблемой. Модель представления вряд ли будет использоваться с другими моделями предметной области, а характер вводимого типа кода (т. Е. Сопоставление) обычно не содержит бизнес-логики, поэтому вероятность того, что нарушение SRP вызовет значительную регрессию в системе, составляет гораздо меньше, чем нарушение SRP на уровне приложения или домена.
Тем не менее, я не считаю процесс добавления логики сопоставления в конструкторы сколько-нибудь значительной экономией времени. Если бы нужно было создать отдельный класс для инкапсуляции сопоставления между объектом предметной области и моделью представления на большинстве языков, мы говорим только о нескольких дополнительных строках кода. Вот разница в реализации:
// constructor
public ViewType(DomainType domainType) {
...
}
// mapper class
public class ViewTypeMapper {
public ViewType Map(DomainType domainType) {
...
}
}
Итак, вы либо выполняете return new ViewType (domainType), либо выполняете return new ViewTypeMapper (). Map (domainType). Я просто не вижу, где развязка в этом случае добавляет существенной работы. В большинстве случаев вы уже зря потратили время и деньги своей компании или клиента, даже обсудив это, потому что в конечном итоге вы неизбежно будете говорить об этом в течение более длительного периода времени, чем если бы вы просто создавали отдельные классы для представления сопоставления, или если вы просто настроите Automapper.
person
Derek Greer
schedule
21.12.2015
