Could there be a base class for customers, employees and suppliers?
-
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?
-
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?
And what if yet another kind of organisation knocks at your door? The government, for example. Perhaps you should get yourself some inspiration from how lawyers deal with different kinds of 'entities'. The real question still is wether or not you are overdesigning, just for design's sake.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
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?
You could have a base class called Contact which would have properties like Name, Address1, Address2, City, Email etc. Then your other classes would Inherit from this class, with the Employee class just having extra Propeties FirstName and Surname, and concatenating these two to provide the Name property, whereas Customer and Supplier would just use Name as Company Name.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
-
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?
Thanks for your answers. I was reading Entity Framework and this is how the question arose: in the database we usually have a table customers and a table employees. Using EF we would get two separate classes for those groups and I was wondering how to deal with inheritance. It seems to me that by using EF we coulnd't use inheritance at all. But this maybe another story...
-
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?
Well, one thing I would advise you to change is the idea that you would put the address in that base class. What happens if your derived class requires multiple addresses? Just something to ponder.
Forgive your enemies - it messes with their heads
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
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?
The real problem is that you haven't defined the problem domain. You can't define your entities if you haven't defined the domain. As an example an small grocery store certainly has customers, employees and suppliers just like an multi-national corporation does. But the grocery store is unlikely to care about any of that if your goal is to write a POS application. That said however it is unlikely that a problem domain that needed a single application that deals with those three entities would use a base class for all of them. And really unlikely if the problem domain called for multiple applications.
-
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?
A reasonable exercise at this point would be to identify the characteristics that you wish to associate with each of the different types. You may well find that there is an hierarchy that you have missed. From experience, there should be a
Personthat is used to represent a physical being [and maybe a role in some cases] and anOrganisationto represent companies [which will havePersoncontacts.Customeris abstract, as it can be aPersonor anOrganisation, and will also reference the list ofAddresses. For your problem domain, these might not all be needed, but they are a good starting point. You need to analyse how you will be using them, before you can decide how they will be used.
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
-
A reasonable exercise at this point would be to identify the characteristics that you wish to associate with each of the different types. You may well find that there is an hierarchy that you have missed. From experience, there should be a
Personthat is used to represent a physical being [and maybe a role in some cases] and anOrganisationto represent companies [which will havePersoncontacts.Customeris abstract, as it can be aPersonor anOrganisation, and will also reference the list ofAddresses. For your problem domain, these might not all be needed, but they are a good starting point. You need to analyse how you will be using them, before you can decide how they will be used.
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:
From experience, there should be a
Personthat is used to represent a physical being [and maybe a role in some cases] and anOrganisationto represent companies [which will havePersoncontacts.Do you mean in a form of nested classes?
nstk wrote:
Do you mean in a form of nested classes?
You are looking at this problem from the wrong direction; forget about the types of classes you need. First define what the problem is and what general process is needed to solve it. Then define the users (people, organisations etc) and what properties they may need. From that information you can start to think about the different classes that will work together to solve the business problem. They may or may not be based on a single base class, but that is not a primary consideration.
Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman
-
nstk wrote:
Do you mean in a form of nested classes?
You are looking at this problem from the wrong direction; forget about the types of classes you need. First define what the problem is and what general process is needed to solve it. Then define the users (people, organisations etc) and what properties they may need. From that information you can start to think about the different classes that will work together to solve the business problem. They may or may not be based on a single base class, but that is not a primary consideration.
Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman
I understand what you are saying but there is no real project. What I am really trying to do, is to find out why and where to use a base class in a hypothetical (but indeed very common) design problematic of, let's say, an ERP software. If we narrow the problem to customers and employees, and assuming that customers are only individuals, it is obvious that both are persons, therefore a base class Persons and two inherited classes of Customers and Employees seems to be very reasonable. But do we need to build a base class in our programme and if yes why? What is the real practical purpose of doing so? In my opinion this generalization of our two "real" classes seems to complicate designing without any having any profit from it. That is my real question to the forum (although some of the answers above have already answered that too).
-
I understand what you are saying but there is no real project. What I am really trying to do, is to find out why and where to use a base class in a hypothetical (but indeed very common) design problematic of, let's say, an ERP software. If we narrow the problem to customers and employees, and assuming that customers are only individuals, it is obvious that both are persons, therefore a base class Persons and two inherited classes of Customers and Employees seems to be very reasonable. But do we need to build a base class in our programme and if yes why? What is the real practical purpose of doing so? In my opinion this generalization of our two "real" classes seems to complicate designing without any having any profit from it. That is my real question to the forum (although some of the answers above have already answered that too).
Sorry but you are asking for a tutorial on OOP; take a look at some of these links[^] which should help you.
Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman
-
Sorry but you are asking for a tutorial on OOP; take a look at some of these links[^] which should help you.
Unrequited desire is character building. OriginalGriff I'm sitting here giving you a standing ovation - Len Goodman
Richard MacCutchan wrote:
Sorry but you are asking for a tutorial on OOP
Well, not really. I 've read already many books about OOP, even studied and done some programmes. I found out that there can be solutions and concepts which vary a lot. In the above example there could be two solutions with or without inheritance between the classes I mentioned. And both could be acceptable and good. Both? Maybe? THat's why I asked here, to get answers from more experienced members. This cannot be done in a tutorial. Thanks for the links.
-
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?
-
Add a class called Company and then add an optional CompanyId (can be null) field to the Person class. That way you can deal with individuals and or individuals from a company.
"You get that on the big jobs."
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
-
Richard MacCutchan wrote:
Sorry but you are asking for a tutorial on OOP
Well, not really. I 've read already many books about OOP, even studied and done some programmes. I found out that there can be solutions and concepts which vary a lot. In the above example there could be two solutions with or without inheritance between the classes I mentioned. And both could be acceptable and good. Both? Maybe? THat's why I asked here, to get answers from more experienced members. This cannot be done in a tutorial. Thanks for the links.
If you want a good insight into design, try The Gang of Four[^], it provides some very good non-language specific information. If you are serious about design, I would suggest it as a must-have.
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:
From experience, there should be a
Personthat is used to represent a physical being [and maybe a role in some cases] and anOrganisationto represent companies [which will havePersoncontacts.Do you mean in a form of nested classes?
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
Agreed: start with the largest discreet object and work back from that.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
I understand what you are saying but there is no real project. What I am really trying to do, is to find out why and where to use a base class in a hypothetical (but indeed very common) design problematic of, let's say, an ERP software. If we narrow the problem to customers and employees, and assuming that customers are only individuals, it is obvious that both are persons, therefore a base class Persons and two inherited classes of Customers and Employees seems to be very reasonable. But do we need to build a base class in our programme and if yes why? What is the real practical purpose of doing so? In my opinion this generalization of our two "real" classes seems to complicate designing without any having any profit from it. That is my real question to the forum (although some of the answers above have already answered that too).
nstk wrote:
What I am really trying to do, is to find out why and where to use a base class in a hypothetical (but indeed very common) design problematic of, let's say, an ERP software.
Again...you start with the problem domain and it defines the classes. If you don't have a problem domain then you cannot defined classes.
nstk wrote:
But do we need to build a base class in our programme and if yes why?
Because the problem domain has requirements that specify that sort of implementation. Or because the problem domain lead to a specific implmentation and that implementation is best implemented that way.
-
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