4.3 Containment

only for RuBoard

4.3 Containment

Containment indicates that one object contains another. Example 4-3 shows a hierarchy of contained classes, each nested within the other; the CreditCard object contains a BillingInfo object, which in turn contains an Address object.

The contained object, if it is used only within the parent object, can be declared as Private . Being restrictive (in terms of scope) at the class level is as important as being restrictive within the class itself. Don't make the class available if it is not needed. Here, Address is an object that could be used by several other classes, such as Order , ShippingInfo , or Invoice . BillingInfo is restricted to the payment and should not exist outside of it.

Example 4-3. Containment relationships
 Public MustInherit Class Payment
  'Payment data
End Class
   
Public Class Address
  'Address1, Address2
  'City, ST, Zip
End Class
   
Public Class CreditCard : Inherits Payment
  
  Private Class BillingInfo
    Private myAddress As Address
    'Methods to get to address here
  End Class
  
  Private myBillingInfo As BillingInfo
   
End Class 

Remember that the classes represent a has-a relationship between the parent class and the child class or classes.

The exception to this rule is the various collection classes that contain a type of an object. In this case, the container's primary behavior is to insert, remove, and maintain the objects it contains.

The same rule regarding accessibility that applies to member data also applies to a contained class; it should be private. The outer class uses the inner class, but the relationship between the two classes should be exposed only through a property.

The containing class should know what it contains, but a contained class should not know what contains it; the contained class should not use the container class in a way that exposes the type of container. Doing so could create a dependency between the two classes and possibly prevent them from being reused.

Many classes in .NET are sealed; they have been declared NotInheritable . They are declared NotInheritable because of performance considerations; it is not a diabolical plot to prevent reuse in the .NET library. In many cases, if a class is sealed, methods that would normally be virtual (determined at runtime) can be inlined by the compiler. In situations like this, containment allows the features of a class to be extended.

To see how this works, consider strings. If you have used VB for any considerable amount of time, you probably have a few string functions from ancient times, before strings were object-oriented. Supposed you'd like to modify the String class to include your old favorites. Guess what? The String class is final, so you're out of luck.

Almost.

Containment is a viable alternative to inheritance in this circumstance. You probably don't need every single public method available from a String , so wrap the ones you do need and delegate to the contained String . This concept is illustrated in Example 4-4, which defines a class called XString that contains a String . The class provides a method called WrapTag , which wraps the string in an XML tag and returns the result. It also provides a Length property that delegates to the internal String class' Length property.

Example 4-4. Using containment for final .NET classes
 Imports System
   
Public Class XString
   
  Private myString As String
   
  Public Sub New(value As String)
    Me.myString = value
  End Sub
  
  'New proprietary string function
  Public Function WrapTag(ByVal tagName As String) As String
    Return String.Format("<{0}>{1}</{2}>", _
                          tagName, _
                          Me.myString, _
                          tagName)
  End Function
   
  'Wrap Length property of String
  Public ReadOnly Property Length( ) As Integer
    Get
      Return myString.Length
    End Get
  End Property
   
End Class
   
Friend Class Test
  Public Shared Sub Main( )
    Dim t As New XString("test")
    Console.WriteLine(t.WrapTag("center"))
  End Sub
End Class 

Contained objects that share the same scope should never be in a uses relationship with one another.

only for RuBoard