OO design: Copying data from class A to B

Having the SOLID principles and testability in mind, consider the following case:

You have class A and class B which have some overlapping properties. You want a method that copies and/or converts the common properties from class A to class B. Where does that method go?

1. Class A as a B GetAsB() ?
2. Class B as a constructor B(A input)?
3. Class B as a method void FillWithDataFrom(A input)?
4. Class C as a st开发者_JAVA技巧atic method B ConvertAtoB(A source)?
5. ???

---

It depends, all make sense in different circumstances; some examples from 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)

Some questions to help you decide:

• Which dependency makes more sense? A dependent on B, B dependent on A, neither?
• Do you always create a new B from an A, or do you need to fill existing Bs using As?
• Are there other classes with similar collaborations, either as data providers for Bs or as targets for As data?

---

I'd rule out 1. because getter methods should be avoided (tell, don't ask principle).

I'd rule out 2. because it looks like a conversion, and this is not a conversion if A and B are different classes which happens to have something in common. At least, this is what it seems from the description. If that's not the case, 2 would be an option too IMHO.

Does 4. implies that C is aware of inner details of B and/or C? If so, I'd rule out this option too.

I'd vote for 3. then.

---

Whether this is correct OOP theory or not is up for debate, but depending upon the circumstances, I wouldn't rule C out quite so quickly. While ti DOES create a rather large dependency, it can have it's uses if the specific role of C is to manage the interaction (and copying) from A to B. The dependency is created in C specifically to avoid creating such dependency beteween A and B. Further, C exists specifically to manage the dependency, and can be implemented with that in mind.

Ex. (in 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

If there is a concrete reason to create, say, a AtoBConverterClass, this approach might be valid.

Again, this might be a specialized case. However I have found it useful on occasion. Especially if there are REALLY IMPORTANT reasons to keep A and B ignorant of eachother.