Note that there are some explanatory texts on larger screens.

plurals
  1. POOOP - Objects For Entities With Master Lists and Object Composition
    text
    copied!<p>I'm trying to wrap my head about how to properly implement an OOP design for business objects that:</p> <ol> <li>Have a "master list" in a database (ex. classifications)</li> <li>Are a part of another object as a property (i.e. object composition) but with additional properties</li> </ol> <p>Here is where I'm stuck on the theory. Suppose that I have a Classification object, inheriting from the abstract class BusinessObject with the CRUD functions defined (MustOverride). This will give me:</p> <pre><code>Public MustInherit Class BusinessObject Public Sub New() End Sub Public MustOverride Function Create() As Boolean Public MustOverride Sub Read(ByVal id As Integer) Public MustOverride Function Update() As Boolean Public MustOverride Function Delete() As Boolean End Class Public Class Classification Inherits BusinessObject &lt;Fields, properties, etc. for ID, Name (or Description), and IsActive. DB table has only these 3 fields.&gt; Public Sub New() MyBase.New() End Sub Public Overrides Function Create() As Boolean Dal.Classifications.Create(Me) End Function Public Overrides Function Delete() As Boolean Dal.Classifications.Delete(Me) End Function Public Overloads Overrides Sub Read(ByVal id As Integer) Dal.Classifications.Read(Me) End Sub Public Overrides Function Update() As Boolean Dal.Classifications.Update(Me) End Function End Class </code></pre> <p>This will allow me to use the Classification object on a form where a system admin can manage the master list of Classifications in the system. No issue here.</p> <p>Now, I want a Customer object to have a property of type Classification (object composition) but with one caveat - the Classification object requires an additional field, Level, when it becomes a property of the Customer object. Level is a logical part of Classification according to the business - a Classification has an application-user-entered numeric level. So I created a class CustomerClassification inheriting from Classification:</p> <pre><code>Public Class CustomerClassification Inherits Classification Private _level As Integer Public Property Level() As Integer Get Return _level End Get Set(ByVal value As Integer) _level = value End Set End Property Public Sub New() MyBase.New() End Sub End Class </code></pre> <p>And the Customer object will be composed of CustomerClassification:</p> <pre><code>Public Class Customer Inherits BusinessObject Public Property Classification() As CustomerClassification ........ etc End Class </code></pre> <p>Now, my design problem is that the Create, Read, Update and Delete functions are still exposed in the CustomerClassification object:</p> <pre><code>Dim c as New Customer c.CustomerClassification.Update() ' &lt;-- Not desirable! </code></pre> <p>What kind of other design could I implement here? It's obvous that I'm designing this the wrong way, but I don't see an easy alternative pattern. I don't want to repeat the code in the CustomerClassification class by not inheriting Classification and repeating all the field and property code, but I also don't want to expost CRUD functions to the CustomerClassification level. What am I missing in looking at the overall class design?</p> <p><strong>EDIT:</strong> Saving the <strong>classification level</strong> to the database will be handled by the customer object, because the database is legacy and the field for Level is defined in the customer table.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload