Designing Question
I am About to Built a new Application for a Merchant.
I have many "Double Objects" like: Vendor and Customer, Vendor Order and Customer Order, Materials and Products etc.
They basically have the same methods and members.
What is the best way to Design the Objects?
I was thinking about having an abstract Object, like company, that "Vendor" and "Customer" would extend.
If I do that, I would be doing it I'm most of my objects, it doesn't sound like the best way to me.
Any suggestions?
[532 byte] By [
carol_aba] at [2007-11-26 18:34:12]
> What is the best way to Design the Objects?
> I was thinking about having an abstract Object, like
> company, that "Vendor" and "Customer" would extend.
>
If you they contain duplicate functionality and would represent a Company this sounds like a good idea.
> If I do that, I would be doing it I'm most of my
> objects, it doesn't sound like the best way to me.
>
> Any suggestions?
Don't forget about interfaces. Also, think about creating a order class that would hold a company, rather than having two kinds of orders.
If they have the exact same methods and members, then they're the same object.
What you described isn't a bad idea at all. Consider interfaces, even considering one extending the other instead of both extending a third class.
But to give you a better answer at what you should do we'd really need a better feel for what your methods and fields are..
K.TempesT
The Application is for a workshop.
I'm in the very early stages of design, so the differences between Vendor and Customer are not clear yet, but I assume there are.
As i see it (In this stage anyway) - there are 2 similar and main operations: working with Customers ("Seller Side") and working with Vendors ("Buyer Side").
Same Functionality, only from different Point of view.
> As i see it (In this stage anyway) - there are 2
> similar and main operations: working with Customers
> ("Seller Side") and working with Vendors ("Buyer
> Side").
> Same Functionality, only from different Point of view.
It isn't even as clear-cut as that.
My company sells to its "suppliers" and buys from its "customers" as well as buying from suppliers and selling to customers. Not on a regular basis, but enough to wish it to be an easy process. Many Management packages keep "suppliers" and "customers" in different tables, which is a pain in the neck for us, requiring duplication and the possibility of loss of visibility of the process.
I would prefer the option of making contacts a "Company", as suggested, and then marking individual transactions as either purchases or sales. This doesn't pre-characterise the contact organisation as either a supplier or a customer, and maintains flexibility.
> I would prefer the option of making contacts a
> "Company", as suggested, and then marking individual
> transactions as either purchases or sales. This
> doesn't pre-characterise the contact organisation as
> either a supplier or a customer, and maintains
> flexibility.
We have this same poblem, but also with many other gotcha's: one such is a supplier can be a customer, with the same physical address, but yet, require seperate billing addresses and phone numbers.
Carol, whatever you decide to do, do not get affixed into a trap at this piont with preconceptions. Get your analysis done that will give you a better definition of "client" and "supplier" and how their attributes can overlap and how they are distinctly different. Once you have that, you can better decide on exactly what you want to do.
You may find you want something like "entity" classes that handle the overlap and seperate classes to handle the differences, but who knows, that is what you'll know better after your analysis is done or at least much further along.
Message was edited by:
morgalr
> I have many "Double Objects" like: Vendor and
> Customer, Vendor Order and Customer Order, Materials
> and Products etc.
> They basically have the same methods and members.
>
> What is the best way to Design the Objects?
> I was thinking about having an abstract Object, like
> company, that "Vendor" and "Customer" would extend.
Don't spend time building inheritance hierarchies. Make every major "object", like Costumer, Vendor etcetera a standalone interface.
Then you'll always find functionality they can share. For example both Costumer and Vendor probably are located somewhere so they'll both need an Address. So you add an Address interface to your design. It will eventually be implemented and in this way Costumer and Vendor will share code but without being related through inheritance. This way of sharing implementation is called composition and it's often preferrable.
