Could there be a base class for customers, employees and suppliers?
-
No. I mean as candidate classes. Begin by writing out in plain English [other languages are available] what you want to do. As an example, your system could be described thus:
Requirements:
Provide software to manage the relationships between the company and it's suppliers and customers. All the contacts can be either individual people or companies. Any company will have one or more contact. Orders are recieved from customers and placed with suppliers for the provision of Widgets and associated products. Every order received will result in an invoice being raised by the accounting system. Orders placed with suppliers will be filled and invoices for payment will be sent to the accounting system. Each order [inbound or outbound] will have a billing address and a delivery address, these need not be the same. Each customer can have default addresses associated with it.
From this initial requirement, you can take out all the nouns and noun phrases. These are your candidate classes. The next stage is to decide which ones are classes in their own right and which are attributes. Often a lot of candidates can be reduced. As an exercise, I would recommend giving this a go and see where it takes you.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
I'd argue the other way around. Company is not an attribute of a person, but a person - as in a contact - is an attribute of a company.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
In a software for a company, we usually have customers, employees and suppliers in what regards humans. Therefore a reasonable (meaning a good one) OOP approach would be to have a class 'Persons' with attributes such as name, surname, address etc. and then let the classes 'Customers', 'Employees' and 'Suppliers' derive from the class 'Persons'. But, on a second thought there is a problem. How do we deal with customers and suppliers which are companies?
I would suggest looking at good MDM[^] designs as they obviously deal with it. I am not saying make yourself an MDM system (or buy/donwload one). I am just saying that MDM deals with so many 'entities' and they of course try to abstract out the overlapping info. I have never really looked into it too much but have dealt with MDM groups. Sometimes their 'naming' is off so it can be confusing, but in the end they get the job done. So if you find some info on MDM architecture you might stumble on to a good base class design.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
And all the customers who are buying products and services for their own personal use. They don't have companies so what do you do about them?
"You get that on the big jobs."
You missed the BIG POINT earlier. A customer is a person or a company, A company also has a person as a contact. I almost feel an article...
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
You missed the BIG POINT earlier. A customer is a person or a company, A company also has a person as a contact. I almost feel an article...
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
Nagy Vilmos wrote:
A customer is a person or a company, A company also has a person as a contact.
What about putting the Persons class as a nested class in the Company class in that case? Complicated?
Not a good idea. The attributes of a person - name, date of birth, sex, etc - are independent of the role they perform. A decent representation of a person will be reusable if you ignore how it is used. Similarly, the concept of a company is independent of the problem domain. A company has employees but, and this is true in real life as much as in a program, the employee does not have a company.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
Thanks for your effort, I really appreciate this great help. I will indeed develop this as an exercise and if there is something to discuss I will write it here. :)
Here is a simple set of candidate classes:
+------------+ | Customer | | | +------------+ | v+------------+ +------------+ +------------+
| Supplier |--->| Contact |--->| Person |
| | | | | |
+------------+ +------------+ +------------+
|
+------+--------+
| impliments |
+------------+ +------------+
| Company | | Individual |
| | | |
+------------+ +------------+
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
Here is a simple set of candidate classes:
+------------+ | Customer | | | +------------+ | v+------------+ +------------+ +------------+
| Supplier |--->| Contact |--->| Person |
| | | | | |
+------------+ +------------+ +------------+
|
+------+--------+
| impliments |
+------------+ +------------+
| Company | | Individual |
| | | |
+------------+ +------------+
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
Shouldn't Person inherit from Contact? The arrow direction between them indicates the opposite situation.
The arrows represents a reference, so a Contact 'has a' Person.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
You missed the BIG POINT earlier. A customer is a person or a company, A company also has a person as a contact. I almost feel an article...
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
I still missed the big point but if you do get around to writing the article, It would be interesting. I guess your talking about some kind of interface that both person and customer implement. Anyway I've just spent the last month discovering values such as the "delivery contact name" being stored in the weather_sunny field. :mad: So I'm a bit paranoid about such things at the moment.
"You get that on the big jobs."