01.Blogs :
RobMiles  
Programming, gadgets and life as a lecturer in a UK university.

Train of Thought

I was doing a lecture for the first year C# course and was talking about design with objects. From the business point of view I'm trying to get a seqeuence of design actions together into a little train of thought. The sequence goes like this:

  1. Identify an object in your system  (for example customer).
  2. Identify a property of the object (for example customer name).
  3. Decide how you are going to store that property (use a string)
  4. Add the property and make it private (then nobody can fiddle with it)
  5. Decide if you need to be able to change it. If you do, add a set method with error checking. Make this public.
  6. Add a get method for your property. Make this public.
  7. Decide if you need to be able to set this value when the object is created. If you do, add it to the constructor.
  8. Repeat for all the other properties (address, phone number, credit limit etc).
  9. You then have a nice shiny object which can hold things and a bunch of methods that describe what it can do. Take all the methods and slap them into an inferface. Make the object implement the interface and manage all the objects in terms of that interface. It is now a component.

I advised the students to look at objects around them and consider how they would be managed in this way, what in them could/should be changed by a program and the data types to be used for each. You can do this on anything. Bus stops, tooth brushes, pens, cheese. I recommend it as a form of mental exercise in object design. You should also think of questions to ask your customer: "Do you need to store the number of bristles on your toothbrush?" for example....

posted on Monday, April 04, 2005 8:49 PM by RobMiles

# @ Tuesday, April 05, 2005 2:54 AM

Hmm.. The Explaination is so wonderful and perfect that it makes me jealous as why i didnt do my undergraduation from University of Hull. I strongly belive this is a perfect way as how ur thought process should be before u go and write a peice of code.

agurha

# @ Wednesday, April 06, 2005 9:13 AM

I disagree about using getters and setters. I think the overhead in terms of pages and pages of these methods for every variable is just too much. I think the code that sets the variables should check they're in the valid range instead of the method - I feel it would be pointless to check using a setter simply because if it does throw an error, the chances are your program will screw up anyway. I think only in rare situations which are dangerous in terms of safety and where a mistake could cost a company a lot of money they should be used - and when they are it will still only be for one or two methods. I think the safety side checks should be performed before the critical action occurs anyway - better to check your microwave is turned off when you open the door rather than when the timer reaches zero and keep a note! Additionally I think you should mention extending another object, particularly if you want an interface (suggesting you will want to add similar objects with slightly different properties in the future). You can then put varibles such as parent, name etc. that are common into this and use it to retrieve this information (when displaying all objects in a list for example) just by casting each object and getting the name property...

Pandilex

# @ Thursday, April 07, 2005 8:10 PM

Sorry Pandilex, I just don't agree. The only object with the authority to decide on whether or not a member has a valid value is the object containing the member. If you spread this over the system you end up with more coupling and less cohesion, which I regard as a bad thing. Very few programs (apart from games) are so time critical as to be sensitive in this way. As to extending, that is something you want to do if you want to reuse component behaviours in another component. I'll see if I can come up with some other rules for that later.

RobMiles

# @ Saturday, April 09, 2005 8:59 AM

The thing is, my final year project for example has a reusable component containing an arraylist. In order to implement getters and setters for that component, it would require one for every single method I wanted to use - Add, Clear, Copy, Remove, RemoveAt etc. and I don't see the benefit of hiding these and having a hundred extra lines of code vs. the benefit of it checking for a valid value. You say that the only object with authority is the object containing the member. However the object containing the object containing the member is being denied access to it. If you have an array of Customers it's your array to do with as you please. Checking you're entering a numeric value for age is going to break your program one way or another, whether its the programmer sending a 'string' and getting a type error, or your code throwing an exception. I don't understand how it couples your program as there is no dependancy. It's just cutting out the middle-man when you need something altering in your object.

Pandilex


 
03.UPDATE CALENDAR :
<April 2005>
SunMonTueWedThuFriSat
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

05.MY LINKS :

07.Subscriptions :

Subscriptions


© Copyright 2005 Microsoft Corporation. All Rights Reserved.
Terms of Use | Privacy Statement | Code of Conduct | Hosted by MaximumASP for Microsoft
WHO-BAR