Blogoforum -
Peter asks JOS readers about where to put validation code in MVC: http://discuss.joelonsoftware.com/default.asp?design.4.354410.6
One technique I use frequently to build good OO models is like this. First thing I do is try to describe my program logic using procedural design. I'm giving the system the best procedural design I can. Important thing here is to follow DRY principle and avoid code duplication.
As a result, I have a set of methods on paper or in my mind. I have pretty actual set of methods, and I know pretty precisely how my program will do some routine, no matter will I use procedural design, static methods, or pure OO design.
Now with this set of methods it is pretty easy to build a good object model. Note methods doing similar or closely related things on same data type. These methods are good candidates to be one object's responsibility.
This technique is well applicable to extend or improve existing code. Describing existing program flow using plain procedures, we can find points of ineffectiveness of our OO code, thus identify improvement opportunities. Describing new functionality with procedures, we can find which classes we will give new code to, or which classes should be refactored or new classes are to be created.
If you want, we can conduct an experiment. Give me a set of procedural routines. No need for actual code, we can use human-word pseudocode. And I'll show you how I would build an object model from them.
What do you think of this technique?
One technique I use frequently to build good OO models is like this. First thing I do is try to describe my program logic using procedural design. I'm giving the system the best procedural design I can. Important thing here is to follow DRY principle and avoid code duplication.
As a result, I have a set of methods on paper or in my mind. I have pretty actual set of methods, and I know pretty precisely how my program will do some routine, no matter will I use procedural design, static methods, or pure OO design.
Now with this set of methods it is pretty easy to build a good object model. Note methods doing similar or closely related things on same data type. These methods are good candidates to be one object's responsibility.
This technique is well applicable to extend or improve existing code. Describing existing program flow using plain procedures, we can find points of ineffectiveness of our OO code, thus identify improvement opportunities. Describing new functionality with procedures, we can find which classes we will give new code to, or which classes should be refactored or new classes are to be created.
If you want, we can conduct an experiment. Give me a set of procedural routines. No need for actual code, we can use human-word pseudocode. And I'll show you how I would build an object model from them.
What do you think of this technique?
by dkrukovsky
June 18, 2006 10:08 AM+ add to your
Readings [?]
Your Reply
del.icio.us