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.