OOP / OOD Вопрос о связи - PullRequest
       1

OOP / OOD Вопрос о связи

1 голос
/ 21 октября 2010

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

Мой вопрос такой:

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

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

Кроме того, разве 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

Ответы [ 4 ]

1 голос
/ 22 октября 2010

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

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

1 голос
/ 22 октября 2010

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

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

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

1 голос
/ 22 октября 2010

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

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

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

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

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

1 голос
/ 21 октября 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...