I am setting out to write a class library for use in a later project, and have not written any real OO code since Turbo Pascal 5.5 days.  I use VB.NET in mostly RAD-style development for Windows Forms and Windows Services, but it's mostly procedural within events.  (ala VB6 round peg in a VS2003 square hole)

I am looking to create a class hierarchy that is not inherited, because they don't share similar base class features.  Rather, it's an organizational hierarchy.  I suspect I need to implement generic collections of a type within each class to establish the hierarchy.  But you tell me.  Here's an example, using post office boxes.

A class library named PostalSystem
A collection of Nations
Each Nation contains Cities
Each City contains PostOffices
Each PostOffice contains POBoxes

Pretty simple, so I'm looking for the design pattern in VB.NET that one would use to establish this.  All would need to be serialized to MSSQL or XML, but that's a later problem.

Anyone have any design pattern books or themselves know how this is properly implemented?

[quote author=Grok link=topic=17128.msg174086#msg174086 date=1193065946]
I am setting out to write a class library for use in a later project, and have not written any real OO code since Turbo Pascal 5.5 days.  I use VB.NET in mostly RAD-style development for Windows Forms and Windows Services, but it's mostly procedural within events.  (ala VB6 round peg in a VS2003 square hole)

I am looking to create a class hierarchy that is not inherited, because they don't share similar base class features.  Rather, it's an organizational hierarchy.  I suspect I need to implement generic collections of a type within each class to establish the hierarchy.  But you tell me.  Here's an example, using post office boxes.

A class library named PostalSystem
A collection of Nations
Each Nation contains Cities
Each City contains PostOffices
Each PostOffice contains POBoxes

Pretty simple, so I'm looking for the design pattern in VB.NET that one would use to establish this.  All would need to be serialized to MSSQL or XML, but that's a later problem.

Anyone have any design pattern books or themselves know how this is properly implemented?
[/quote]

I've briefly read through these, which are pretty known design pattern books, more C++ OO than .NET (ebooks can be found):

- Addison Wesley - Design Patterns - Elements of Reusable Object-Oriented Software

- Design Patterns Explained: A New Perspective on Object-Oriented Design
By Alan Shalloway, James R. Trott

- Modern C++ Design: Generic Programming and Design Patterns Applied
By Andrei Alexandrescu

Thanks for the quick reply, though I can get a list of design pattern books from any bookstore website.  I was rather hoping someone had a book and could describe the pattern, or someone with significant .NET experience, especially in 2.0 FCL, would suggest the recommended implementation, or idiom, to solve this simple problem.

I don't understand; are you looking for a class diagram?

[img]http://www.jinxbot.net/pub/grok.jpg[/img]

If you're looking for something in terms of how to manufacture these objects, I would suggest utilizing a factory pattern.  For our larger projects at work, we utilize a standard factory-based pattern in our web applications; essentially, we define a series of data classes in the "business" tier of our application (these classes would correspond to the classes you listed and I modeled in the above diagram).  This tier is implemented in a single assembly - a .dll file - which can be referenced elsewhere in the project.  For your project, you might call it PostOffice.Data.dll.

Within the same .dll, we also define a series of abstract classes.  Since we typically build websites, we call our root factory object a SiteProvider; it might be appropriate for yours to be ApplicationProvider or ApplicationFactory.  This object is implemented as a singleton, is initialized lazily according to information provided in the application configuration file, and exports a series of properties that refer to abstract objects.  Consider the following class definition:

[code]
Public Class ApplicationProvider

    Private Shared Dim s_instance As ApplicationProvider
    Private Shared Dim s_lock As New Object()

    Public Shared Property Instance As ApplicationProvider
        Get
            SyncLock s_lock
                If s_instance Is Null
                    s_instance = CType(Activator.CreateInstance(Type.GetType(ConfigurationManager.AppSettings("AppDataProvider"))), SiteProvider)
                End If
                Return s_instance
            End SyncLock
        End Get
    End Property

    Public ReadOnly MustOverride Property NationProvider As NationProvider

End Class
[/code]
Within the app.config file, you should also have:
[code]
<configuration>
    <appSettings>
        <add name="AppDataProvider" value="PostOffice.Data.SqlClient.SqlApplicationProvider, PostOffice.Data.SqlClient" />
    </appSettings>
</configuration>
[/code]

The value provided within that app.config setting is the fully-qualified type name of an implementation class - fully-qualified meaning that it's got the namespace and class name, plus the assembly it's housed in.

From this type of architecture, we then create a number of other classes that define the specific retrieval and save functionality.  All of this goes into the primary data .dll.

Then, we create another .dll - one that's specific to your persistence medium.  We typically follow the naming convention ProjectName.Data.SqlClient (because SqlClient is the Microsoft namespace for SQL Server 2005).  This assembly creates the implementation classes of all of the abstract classes we defined before.  This ultimately creates the persistence media agnosticism we all search for by using design patterns.

Hopefully this helps you out a bit.  If you need more concrete code examples, let me know.