How to Structure Classes

I could greatly use some guidence with structuring my classes. I am new to classes in VB.NET.

I have the following business objects/structure.
           1) Entity (Vendor, Company)
           2)  Person (Employee, Client, Vendor)
           3)  Contracts( New Solicitation, Monitor Contracts, Bid On COntracts, Contract Won, Earned/Billed Revenue)
           4) then I have a collection of shared actions  and behaviors for the application to render, display, and interact with these three main objects.
           I am not sure if I should group the many shared functions into a common class or group them tighly with the three main objects. For example, getPersonPicture(userID) is meant to use a user's GUID to get a user picture for a control.

I am looking for a very rough/dirty guidence and any help appreciated. thanks!!!
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jeff CertainCommented:
The best thing you can do is make sure that you design your classes from an object-oriented perspective. (I know that sounds obvious, but it's a common failing in those moving from VB6/VBA to VB.NET.)
Robert C Martin's ("Uncle Bob") SOLID guidance is a good starting point. Specifically, give each object a single responsibility as much as possible. In your case, this means that the Person object should have a Picture property. How that property gets the picture is up to you -- there's benefits to loading it when the person is instantiated, or when the picture is required. In either case, you shouldn't need to pass in the UserId to the method -- the Person already has the Id property internally.
There may be some common code that gets pulled out of classes, and built into utility classes. For example, data access should be isolated from your actual class and, in general, there's a lot of commonality between the data access classes. However, this quite often means that you'll need to introduce a superclass (parent class) that the other classes inherit from.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
anyoneisSoftware DeveloperCommented:
The obvious answer is often to put common code in base classes (Person) and derive other classes from that base (Employee, Client, Vendor). However, the obvious answer is often wrong and is certainly not a best practice. "Prefer composition over inheritance" is the catch phrase. Here, it means you could add a property in each of the three classes that has a reference to a Person class.
Old-timers might rephrase this as "Prefer has-a to is-a".This principle helps the classes to have better decoupling - or as said above, to have a single concern. An Employee class never has to worry about what it is like being a Person - it just knows that it has a Person aspect that can be evoked to handle Person /Questions/Behaviors.
Continuing on the road to better design, you run into the phrase, "Program to an interface, not an implementation." Heeding that call, each of the three classes mentioned above would have a property which was a reference to an IPerson (a person interface) rather than a Person, and the Person class would then implement IPerson.
Now you can create an Employee object without have a Person instance, you just need to supply an instance of something that implements an IPerson interface. This has advantages for testability and adaptability of code.
There's much more, but these two principles are a good start.
And, just to play devil's advocate, you might read:
anyoneisSoftware DeveloperCommented:
I forgot to address your example: getPersonPicture(userID) is probably just a Picture property on the IPerson interface and the Person class.
I also forgot to address your question of what to do with common code that does not reside within the proper (e.g. very narrow) set of concerns of the Person class or any other erstwhile base class. Be sure that it is truly the code which is common, and not just the behavior. For instance, a single routine to Render instances in the three classes above would likely have a switch statment in it - that's a mark of multiple concerns and a danger signal - I would have a separate method in each class ...or...
I would have each of the three classes contain a reference to an object that implemented the IRenderable interface. Then, implement the interface in a class that implements the IRenderable interface, and put an instance of such a class in instances of the three classes at the time of instantiation.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Programming Theory

From novice to tech pro — start learning today.