ОО дизайн: Копирование данных из класса А в В - PullRequest
Новая
       22

ОО дизайн: Копирование данных из класса А в В

0 голосов
/ 26 января 2011

Имея в виду принципы SOLID и тестируемость, рассмотрим следующий случай:

У вас есть класс A и класс B, которые имеют некоторые перекрывающиеся свойства.Вам нужен метод, который копирует и / или преобразует общие свойства из класса A в класс B. Куда идет этот метод?

  1. Класс A как B GetAsB ()?
  2. Класс B как конструктор B (вход A)?
  3. Класс B как метод void FillWithDataFrom (Aвход)?
  4. Класс C как статический метод B ConvertAtoB (Источник A)?
  5. ???

Ответы [ 3 ]

1 голос
/ 26 января 2011

Зависит, все имеет смысл в разных обстоятельствах;некоторые примеры из Java:

  1. String java.lang.StringBuilder.toString()
  2. java.lang.StringBuilder(String source)
  3. void java.util.GregorianCalender.setTime(Date time)
  4. ArrayList<T> java.util.Collections.list(Enumeration<T> e)

Несколько вопросов, которые помогут вам решить:

  • Какая зависимость имеет больше смысла?Зависимый от B, B зависимый от A, тоже?
  • Вы всегда создаете новый B из A, или вам нужно заполнить существующие B, используя As?
  • Существуют ли другие классы?с аналогичными коллаборациями, либо в качестве поставщиков данных для B, либо в качестве целей для данных As?
1 голос
/ 26 января 2011

Я бы исключил 1. потому что следует избегать методов получения ( скажи, не спрашивай принцип).

Я бы исключил 2. потому что это похоже на преобразование, и это не преобразование, если A и B - это разные классы, у которых есть нечто общее По крайней мере, это то, что кажется из описания. Если это не так, ИМХО тоже будет вариант 2.

Означает ли 4., что C знает о внутренних деталях B и / или C? Если так, я бы тоже исключил эту опцию.

Я бы проголосовал за 3. тогда.

0 голосов
/ 27 января 2011

Является ли это правильной теорией ООП или нет, предстоит обсудить, но, в зависимости от обстоятельств, я бы не стал исключать С довольно быстро. Несмотря на то, что она создает довольно большую зависимость, она может использоваться, если особая роль C заключается в управлении взаимодействием (и копированием) из A в B. Зависимость создается в C специально, чтобы избежать создания такой зависимости между A и B. Кроме того, C существует специально для управления зависимостями и может быть реализован с учетом этого.

Ex. (в vb.Net/Pseudocode):

Public Class C
    Public Shared Function BClassFactory(ByVal MyA As A) As B
        Dim NewB As New B
        With B
            .CommonProperty1 = A.CommonProperty1
            .CommonProperty2 = A.CommonProperty2
        End With
        Return B
    End Function
End Class

Если есть конкретная причина для создания, скажем, AtoBConverterClass, этот подход может быть действительным.

Опять же, это может быть специализированный случай. Однако я нашел это полезным в некоторых случаях. Особенно, если есть ДЕЙСТВИТЕЛЬНО ВАЖНЫЕ причины держать A и B в неведении друг о друге.

...