One table many classes

Question

Say I have a database structure like this:

create table Product(id int not null identity,Name varchar(30))
INSERT INTO Product VALUES ('ProductA')
INSERT INTO Product VALUES ('ProductB')

and a class structure like this:

    Imports System.Data.SqlClient

Public Class Product

    Protected ProductName As String

    Public Overridable Sub Display()

    End Sub

End Class

Public Class ProductA
    Inherits Product

    Public Sub New(ByVal product As String)
        ProductName = product
    End Sub

    Public Overrides Sub Display()
        'Specific logic to display product A
    End Sub

End Class

Public Class ProductB
    Inherits Product

    Public Sub New(ByVal product As String)
        ProductName = product
    End Sub

    Public Overrides Sub Display()
        'Specific logic to display product B
    End Sub

End Class

Public Class Form1

    Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        Dim p1 As Product
        Dim p2 As Product

        p1 = New ProductA("ProductA")
        p2 = New ProductB("ProductB")
        p1.Display()
        p2.Display()
    End Sub
End Class

There is a Property (Product) that identifies, which product the class relates to. This does not look correct to me. Is there a better way of modelling it? This is similar to the NHibernate concept of a Discriminator (I am not using NHibernate in this case).

I see no real question..modelling it to do what, exactly? Seems like a unnecessary inheritance, unless there's more than you are showing here (which I assume there is). — Kaizen Programmer, Feb 11 '13 at 21:23
@fab, I have added more code in an attempt to make the question clearer. — w0051977, Feb 11 '13 at 21:51
Still nothing that justifies different classes for ProductA and ProductB — Fabian Schmengler, Feb 11 '13 at 21:55
@fab, I have edited the code again. I am trying to explain the problem using a simple example. The actual problem domain is much more complex. — w0051977, Feb 11 '13 at 22:02
Now it looks like the product classes have too many responsibilities (i.e. more than one) - it's always better to separate business logic and presentation. I know, you said, the actual domain is more complex, but if this means your example does not tell me much about your actual design decisions, you cannot get a specific answer. I'll link you a generic one, hth: http://stackoverflow.com/a/3579462/664108 — Fabian Schmengler, Feb 12 '13 at 06:29

ThinkingStiff · Accepted Answer · 2013-02-11T22:06:24.353

0

With you latest change, you should move your constructor to the base class. Aside from that, the design is fine.

Public Class Product

    Protected ProductName As String

    Public Sub New(ByVal product As String)
        ProductName = product
    End Sub

    Public Overridable Sub Display()

    End Sub

End Class

Public Class ProductA
    Inherits Product

    Public Overrides Sub Display()
        'Specific logic to display product A
    End Sub

End Class

Also, in your declarations you can use the inherited class:

Dim p1 As ProductA
Dim p2 As ProductB

edited Feb 11 '13 at 22:06

answered Feb 11 '13 at 21:23

ThinkingStiff

64,767
30
146
239

I have added more code in an attempt to make the question clearer. – w0051977 Feb 11 '13 at 22:01
The inherited classes override functions and sub routines from the base class. – w0051977 Feb 11 '13 at 22:04
What happens if you change the name of ProductA to ProductZ. Then you would have to change the client code to reflect it i.e. change p1 = New ProductA("ProductA") in Form_Load to: p1 = New ProductA("ProductZ"). I was wandering if there was a way of avoiding this. Perhaps I am overthinking the problem? – w0051977 Feb 11 '13 at 22:09
@w0051977 If a single `Product` class can only have one product name (i.e. class `ProductA` can only have `ProductName = "ProductA"`) then it should be hardcoded, like you had it originally. What's the point of loading the name from the DB at that point? – ThinkingStiff Feb 11 '13 at 22:12
In case the name ever changes. I don't think it ever will, but I believe that other develoeprs cater for scenarios like this. – w0051977 Feb 11 '13 at 22:16

One table many classes

1 Answers1