|
-
Apr 15th, 2011, 06:29 AM
#1
Re: what's so great about classes?
 Originally Posted by Jefals
So, the next time somebody wants something a little different. Instead of the residential customers, they want residential customers with good credit. Now, do I make another class for this, where most of the code is the same, but just minor difference? Or they want commercial customers instead of residential.
Let's say I know that I'm going to have lots of requests like this, but they're all going to have slightly different "wrinkles". Would I still make a class for something that's probably only going to be used by one application? Or, make a more general class -- ( say, I know they always will want the customers whose numbers are greater than 10, and they will always want at least the name and address). Would I just put that general stuff inside the class, and then code the particulars outside of the class?
No, you don't need a separate class for each type of customer, unless they differ from each other in a very significant way. A customer is a customer and the type is just one of its properties.
A class can have properties/fields, behavior (subs/functions), events.
What you are saying is just a property of the customer. So
Customer Type (Residential/non-residential etc.)
Credit (good/bad etc.)
A class will always be required. It is a like a template for your objects. It helps in creation of your objects and defines its properties, behavior and events.
It is always a good idea to code your classes in a general way, though if you know that you will never never need any customer data with number less than 10, you can put the restriction inside the class.
-
Apr 15th, 2011, 08:54 AM
#2
Thread Starter
Member
Re: what's so great about classes?
 Originally Posted by Pradeep1210
No, you don't need a separate class for each type of customer, unless they differ from each other in a very significant way. A customer is a customer and the type is just one of its properties.
A class can have properties/fields, behavior (subs/functions), events.
What you are saying is just a property of the customer. So
Customer Type (Residential/non-residential etc.)
Credit (good/bad etc.)
A class will always be required. It is a like a template for your objects. It helps in creation of your objects and defines its properties, behavior and events.
It is always a good idea to code your classes in a general way, though if you know that you will never never need any customer data with number less than 10, you can put the restriction inside the class.
But the functionality to return the set of customers I'm interested in changes. One application wants to see customers regardless of their credit, the other only wants those with good credit. Do I understand you correctly then, that I would want the class to return the credit where I could examine it external to the class?
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|