OOP/OOD Соединительный вопрос

Question

У меня есть функция, которая возвращает заказы за данный период. Я создаю объект Period, который гарантирует, что при указании диапазона дат дата начала равна < = до даты окончания. Аналогично, если речь идет о месячном периоде, даты начала и окончания периода должны быть соответственно в первый и последний дни месяца.

Мой вопрос заключается в следующем:

Я думал, что в объектно-ориентированных принципах проектирования, сцепление было плохо. Могу ли я ввести связь между классами Order и Period, если класс Order использовал класс Period в качестве параметра в одном из своих методов?

Мое предположение да, но есть преимущества этого, а именно, когда объекты определены, не нужно выполнять одни и те же проверки проверки параметров каждый раз, когда период передается как параметр для разных методов класса ордеров.

Кроме того, не постоянно ли Microsoft передает неинтерминированные объекты одного типа другим объектам?
Избегайте сочетания звуков, таких как отказ от повторного использования для меня, который должен был продвигать ООП. Это похоже на конкурирующие цели.

Может кто-то уточнить.

Public Class Order 

    Public Shared Function GetOrders(ByVal customerId As Integer, 
            ByVal forPeriod As Period) As Orders 

     **'Should the param object MonthPeriod be replaced with 2 date params? 
     'Would I be "reducing coupling" by doing so, a good thing.** 

    End Function 

End Class 

Public Class Period 

    Property FromDate As Date 
    Property ToDate As Date 

    Public Sub New(ByVal fromDate As Date, ByVal toDate As Date) 

     If fromDate > ToDate Then 
      Throw New ArgumentException("fromDate must be less than Or equal toDate") 
     End If 

     _FromDate = fromDate 
     _ToDate = toDate 

    End Sub 

End Class 

Public Class MonthPeriod : Inherits Period 


    Public Sub New(ByVal fromDate As Date, ByVal toDate As Date) 

     MyBase.New(fromdate, toDate) 

     If fromDate.Date <> New Date(fromDate.Year, fromDate.Month, 1) Then 
      Throw New ArgumentException("fromDate must be the first day of the month") 
     End If 

     If toDate.Date <> New Date(toDate.Year, toDate.Month, Date.DaysInMonth(toDate.Year, toDate.Month)) Then 
      Throw New ArgumentException("fromDate must be the last day of the month") 
     End If 

    End Sub 

End Class 

Answer 1

Все в .Net - это объект, и все же объекты редко существуют изолированно, поэтому будет определенная связь между классы да. Вопрос, который вам нужно задать, - это классы, тесно связанные, несколько связанные или слабо связанные. Тесно связанные классы создают хрупкую архитектуру, поскольку изменения могут иметь эффект пульсации во всей модели или системе. Поддержание классов со временем становится все более сложным. Устранение некоторых из этих проблем приводит к тому, что ваши классы более слабо связаны. С точки зрения того, что-то слабо связаны или нет (от here):

Муфта относится к степени прямого знания, что один класс имеет из другого. Это не должно быть интерпретировано как инкапсуляция против неинкапсуляция. Это не ссылка на знание одного класса атрибутов другого класса или , а знание этого самого другого класса.Сильная связь возникает, когда зависимый класс содержит указатель непосредственно на конкретный класс , который обеспечивает требуемое поведение . Зависимость не может быть заменена, или ее «подпись» изменена без изменения изменений в зависимом классе. Loose возникает, когда зависимый класс содержит указатель только на интерфейс , который может быть , реализованный одним или несколькими конкретными классами .

В вашем примере вы ввели некоторую связь между классом Order и классом Period. Вы предположительно должны передать две связанные даты в метод Order, и вы решили создать класс Period для этого. Зачем? Потому что у вас было две даты; a с даты и до настоящего времени; и вы хотели подтвердить, что дата была позже, чем с даты из одного и только одного места в вашем коде. Это приложение DRY principle; и это хорошо. Применение СУХОЙ принципе, в то время как связанные, в отличие от повторного использования кода (от here):

Некоторые характеристики, которые делают программное обеспечение легко многоразовые являются модульность, слабосвязанности, высокое сцепление, сокрытие информации и разделение проблем.

Свободное соединение является лишь одной из нескольких характеристик, позволяющих повторное использование кода. Повторное использование кода будет в какой-то мере способностью использовать класс Period в другом месте вашего кода, а не только для класса Order. Если бы вы добавили интерфейс для абстрактного использования вашего класса Period, это сделало бы ваш класс Order и Period более слабым, но это не уберет вашу способность повторного использования кода (ваша способность использовать класс Period в другом месте в вашем коде).

Answer 2

Свободные связи и повторное использование действительно являются конкурирующими понятиями. При разработке программного обеспечения вы должны постоянно балансировать использование обоих.

Answer 3

Это нормально для служб (таких как GetOrders) в вашей системе, чтобы они зависели от небольших, легко создаваемых объектов Value (например, Period). Это позволяет вашим объектам службы говорить с точки зрения домена, в котором вы работаете, а не всегда в базовых типах.

Поэтому я бы сказал, что переход в GetOrders в этом сценарии правильный. Он поднимает уровень абстракции. GetOrders интересуется всем классом Period, поэтому вы не излишне уменьшаете рамки понятий, о которых знает GetOrders (это просто в другой форме). Если бы Период был намного более крупным классом, содержащим множество других вещей, то соединение было бы намного более проблематичным.

Второй фактор, который делает это нормально, заключается в том, что создание объекта Period легко. Если вам потребовалось создать целую серию других объектов, это будет проблемой. Вот почему у вас нет объектов ценности, отправляющих электронные письма и сохраняющих себя в базе данных и т. Д.

Answer 4

Следует избегать ненужной связи, но в вашем сценарии период просто используется для определения типа значения, который объединяет некоторые понятия о вашем домене, поэтому это неплохо. Если это не зависит от типа значения, вы захотите отделить их, используя технику, такую ​​как инъекция зависимостей (DI) и инверсия управления (IoC).

С точки зрения измерения дизайна, когда дело доходит до зависимости, вам придется смотреть за пределы уровня класса, но больше на пространстве имен или уровне сборки. В вашем случае, если Период живет в том же пространстве имен или сборе, то у вас все еще есть очень хорошая Relational Cohesion между вашими типами в пакете. Ваша эфферентная и эмоциональная связь вашего пространства имен по-прежнему останется неизменной/низкой в ​​приведенном выше сценарии.