• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 366
  • Last Modified:

ASP.NET (VB) OOP Design Question

EE:

Wondering if there are any pitfalls with approaching OOP design of a system which has several relationships/shares common properties using the below example.  

Is this okay to do?  I'm wanting to know if this is good design and common in OOP design/modeling of a system when many classes share the same properties.  I'll provide more info if this isn't enough to pass opinions.

Public Class Person

    Public Property Name() as String
    ......
    End Property

    Public Property Addr() as Address  <----- Is this a good approach?????
    ....
    End Property

End Class

Public Class Address

    Public Property StreetAddr() as String
    .......
    End Property

    Public Property StreetAddr2() as String
    .......
    End Property

    Public Property City() as String
    .......
    End Property

    Public Property ZipCode() as String
    .......
    End Property

    Public Property StreetAddr() as String
    .......
    End Property

End Class


I appreciate your feedback in advance.

SK
0
sk1922
Asked:
sk1922
  • 6
  • 3
  • 3
  • +1
1 Solution
 
gkuhrd2001Commented:
Hi,

I think you should use inheritance instead of containership for object.
becuase in your approach, if you need to access City property of class Address then you need to access 3 memory addresses as
objPerson.objAddress.City   (Your scenerio)

Now if you use inheritance then
objPerson.City

According to me it will increase your performance as well.

Regards
Ankit

 
0
 
sk1922Author Commented:
Ankit:  Thank you for your feedback!

Inheriting a Class -- then if I need to use other classes as part parameters I should use 'Imports'?

So sticking with this example but differ scenario... would this be a better design approach?

-------------------------------------
Imports Person

Public Class AddressChangeRequest
   Inherits Address

   Public Property SomeProp() As String
   ...........
   End Property

   Public Sub SubmitRequest(ByVal p As Person)
   .......
   End Sub

End Class

----------------------------------------
0
 
Asim NazirCommented:
Hi,

IMports has nothing todo with design/oop or any other style of programming. Imports actually allows you to access class members directly without using fully qualified name. e.g.

Say you want to work with RegEx in c#. Now there are two ways to work with this:
System.Text.RegularExpressions.RegEx.....
or
you can use Imports System.Text.RegularExpressions and then you can use RegEx.(any method) directly without prefixing with fully qualified name i.e. System.Text.RegularExpressions

I hope it helps.
Asim
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
gkuhrd2001Commented:
Hi,

I agree with Asim.
Imports will give you access to member without fully qualified name.

I think you should create an event/method in class Address like AddressChangeRequest so that it can work on same member variables without passing object. It will save time at runtime because this already have all the refrence to the data.
If you create a new class for Address Change then you have to pass the objects to that class as you did in your example. In that case, again a refrences will be created as a refrence variable of that class will be created. Again it will cause the same problem in accessing variable.
First it will access the addredd of refrence variable then main object address then any property.

So in my point of view, createing a new Method/Event will be a good idea instead of creating a new class for working on another class data.

Regards
Ankit
0
 
sk1922Author Commented:
What about cases where the Request (i.e. AddressChangeRequest) will need it's own properties?

So let's say Public Property for ModifiedDate, ModifiedBy, Approved By...


Thank you both for your feedback.

0
 
Asim NazirCommented:
Ok. See, all the properties necessary in One class or those peroperties that can be shared further to child will remain at parent level. So ClassOne will have its own peroperties and properties that would be available to child.
Next child will follow the same rule for its own child and for itself.

There will be Address class with say:
Address line 1, address line2, phone etc
AddressChangeRequest will inherit Address, so it will have access to all the properties in  Address. Further it will have its own properties like:
ChangeRequest date

I hope this helps.
0
 
sk1922Author Commented:
Thank you sir for your feedback.

That's kinda what I had in mind after reading the first post by gkuhrd2001.  

Here was my design approach/idea - let me know what you think....

Now this would the same design appoach I'd take with Employee, Salary and Job... so I'm trying to create a consistent pattern (may not work for every single case) but majority of the design could follow the below...

Public Class Address
    Public Property StreetAddr() as String
    .......
    End Property

    Public Property StreetAddr2() as String
    .......
    End Property

    Public Property City() as String
    .......
    End Property

    Public Property ZipCode() as String
    .......
    End Property

    Public Property StreetAddr() as String
    .......
    End Property
End Class


Public Class AddressChangeRequest
   Inherits Address

   Public Property RequestID() As Integer
   .........
   End Property

   Public Property RequestDetailID() As Integer
   .........
   End Property

   Public Property RequestDate() As Integer
   .........
   End Property

   Public Sub SubmitChangeRequest(byval empID As integer)
   End Sub

End Class

Open in new window

0
 
Asim NazirCommented:
Yes. This looks fine. Keep one thing in mind that whenever you have complex and dependent entities only then we need to follow this model.

Asim
0
 
TommySzalapskiCommented:
I disagree with the above discussion.
Inheritance is for objects that are similar to the original but have more details attached to them. What if your person class has an address and owns a car? Are you going to inherit from both classes? What if you decide someone can have a work address and a home address? Inheriting the Person class from the Address class is rediculous. A person is not a subclass of an address. A person has an address.

Inheritance alse creates replication. Your address change request should either be a container (like in the original post) or refer to it by some ID or even a pointer. If you have the container (or inheritance) then you will have to copy all the data into the new structure (slower and higher RAM cost).
0
 
TommySzalapskiCommented:
Modern compilers optimize so well anyway that inheritance isn't going to be any faster than using a container anyway. Your original solution is simpler, more robust, more scalable, less prone to errors, and as fast if not faster.
0
 
sk1922Author Commented:
I'm still rather confused since it's been somewhat mixed feedback.

TommySzalapski:  
Thank you for your kind response.  

Im still unsure of the right approach. My initial design was:

Class Person
Class Employee - inherits Person
Class Job
Class Position - inherits Job
Class Salary
Class Address
Class HRRequests
Class HRRequestDetails - inherits HRRequests
Class AddressChangeRequest - inherits HRRequestDetails
--- container: Address
Class SalaryChangeRequest - inherits HRRequestDetails
--- container: Salary
Class JobChangeRequest - inherits HRRequestDetails
--- container: Position
Class NewPositionRequest - inherits HRRequestDetails
--- container: Position
Class NewHireRequest - inherits HRRequestDetails
--- containers: Employee, Position, Salary


this design is for an HRIS system that I'm working on in case it wasn't obvious. So think of all the objects which are part of an employee's file.  So you can imagine all of the complex relationships... Also... Company info - locations, divisions, departments... So containership for these would exist in this system as well as others.
0
 
sk1922Author Commented:
Forgot to add

Person
-- container: Address
Employee - inherits Person
-- containers:  Position, Salary, Location, Department, Division

I know I'm leaving out a lot more but should be enough to draw a conclusion.
0
 
TommySzalapskiCommented:
That design makes sense to me. An employee is a person so the inheritance makes sense. An employee has a salary, so the container makes sense.
Now, for things like
Class NewHireRequest - inherits HRRequestDetails
--- containers: Employee, Position, Salary
I would use a reference of some kind to the employee instead of containing it so that you don't have any replication. You don't want the same employee in there multiple times, because details (like address) might change and the change would need to be pushed to all the replicas. I would have it include the Employee ID or a pointer to the Employee object depending on how it's supposed to work.

Is the data stored in a database somewhere?
0
 
sk1922Author Commented:
Yes sir, all the data is in a DB.

The referencing makes sense to me.  I'm thinking then that all of my *ChangeRequest classes should import rather than contain:

-Imports Employee, Salary, Position

Public Class NewHireRequest
End Class
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 6
  • 3
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now