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

Question

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

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

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

Answer 1

Это зависит, все имеет смысл в разных обстоятельствах; некоторые примеры из 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)

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

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

Answer 2

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

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

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

Тогда я проголосовал бы за 3..

Answer 3

Является ли это правильной теорией ООП или нет, для обсуждения, но в зависимости от обстоятельств я бы не стал так быстро выходить из C. В то время как ti создает довольно большую зависимость, он может использовать его, если конкретная роль 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 невежественными друг друга.