design infrastructure for a corporation

[vcllvc]

how would you do for designing classes for an entirly corporation?

Let's say I have a customer base class and then some child customer classes inherit from it.

So, what is the best practice of managing them and using them?

I would put them within the corporation's namespace and add reference to it everytime I need them.

But my problem is should I include methods on the base class or just have some shared properties within the base class?

thanks for any comments.

 

[h0h0h0]

Not really something that there's a short and easy answer to vc.

In response to the implementation question - depends on what you want - i wouldn't implement properties. I typically do a customerclass.display(displayobject) or something. I pass in the item to the class and make the class do the work. This may be an unpopular idea. Customerclass.persist(); new Customerclass (Customername..,..,..,..); Make the object do the work.

As for the management issue you have - Let me ask you this. How many developers are in the company? How big is it and where is the growth at?

Make your objects extensible. A customer should just be a customer short/long name and an ID. everything else such as address should hang off of it as another object.

Try it with whatever way you feel comfortable with - you seem to be just starting out with OOP stuff if you have this question so you're really going to have to make some mistakes at first before you realize what the better decision is. Everyone went through it..

 

[cpjust]

What programming language(s) will you be using?

You should make the Customer base class either an abstract class or an interface. Only make things public if it's absolutely necessary.
I'd stick with Get/Set methods that can do additional error checking, rather than properties that anyone can modify.

Write down all the attributes you'll need to store in your customer records, split them up into different types of customers, and figure out which ones are generic enough to apply to all customers (i.e. the base class).

Getting the class design and interface right at the beginning is much better than having to make changes later that require all other classes in the hierarchy to change also.

 

[vcllvc]

I am using c#.

I agree with cpjust that using the get/set methods which is called the properties in c#. And I strongly agree that getting the design right at the beginning is very important.

So when you design a class, do you also implement the methods within the class, or implement another helper class that does all the functionality?

 

[cpjust]

Are you referring to the Pimpl idiom?
I've never used it yet, but if I were designing a class that will be used by a lot of other components, I'd probably lean towards a Pimpl.

If you search for "Pimpl idiom", you can find lots of sites like this:

http://www.devx.com/cplus/Article/28105

This book also has a lot of useful info you'd be interested in:

http://www.awprofessional.com/title/0201615622

 

[h0h0h0]

I typically make the functionality as discrete as possible so yeah i use helper classes for the most part.

 

[grooke]

Hmmm!
There is one thing that you MUST be aware of. Making a hierarchy of 'Customer', 'CustChild1', 'CustChild2', etc can be very dangerous.

What if [tab] CustChild1 is a Cash Customer
[tab][tab][tab]CustChild2 is a Account Customer
[tab][tab][tab]CustChild3 is a Trade Customer, who may be either of the above.

Do NOT inherit directly. Do it as follows:
[tab][tab][tab]Customer is a base class. It has (Composition) a class called 'ClassType.
[tab][tab][tab]The three children inherit from this.
Then you can have
[tab][tab][tab]Trade customers who pay by cash,
[tab][tab][tab]or Trade customers who have an account.
You can also upgrade a cash customer to having an account.

Then follow the advice that the others have given.

I'm also suspicious of putting business logic into 'display' classes.
[tab][tab][tab]Keep the Business logic in business classes
[tab][tab][tab]Keep the display parameters in the display class and
[tab][tab][tab]link the two through a control class, which should be controlling the steps outlined in the use case.

Gil

 

[h0h0h0]

I used to be suspicious but not anymore.. And you're not really putting display logic in the business class at all - you're delegating the functionality to different classes that know how to do the work but instead of

DisplayClass(Customer);
it's
Customer.render();

 

[grooke]

Sorry. I misread

I typically do a customerclass.display(displayobject) or something. I pass in the item to the class and make the class do the work.

It sounds as though you are making the display class do the work. As a result I said

I'm also suspicious of putting business logic into 'display' classes.

which you somehow read as

And you're not really putting display logic in the business class at all -

which is the opposite of what I said.

Gil

 

[h0h0h0]

this is like a monty python skit.