- Procedural -- Code written in procedural and sequential style. Uses primitive types and common data structures. Multiple steps and conditions are defined in a single or few massive methods to reach program to a happy state.
- Object-Oriented -- Code written in object-oriented style. Uses beans, DAOs, manager objects, etc. Code is constantly refactored, such as decomposing and using "extract method".
For example, in a procedural manner,
public MyActionClass{
public void doAction(){
Map vars = new HashMap();
if(condition1){
SomeClass.doSomething(vars);
SomeClass.doTransaction(vars.get("var1"));
}
else{
// .. Something similar
}
SomeClass.finalizeSomething(vars.get("var2"));
}
}
In an object-oriented manner,
public MyActionClass{
public void doAction(){
MyActionContext context = MyActionThreadLocal.getContext(); // Or a bean, or something similar
if(condition1){
doTransactionForCondition1(context);
}
else{
// .. Something similar
}
SomeClass.finalizeSomething(context.getVar2());
}
protected void doTransactionForCondition1(MyActionContext context){
SomeClass.doSomething(context);
SomeClass.doTransaction(context.getVar1());
}
}
Whatever above is just a very small piece of code, imagine in a class with complex business logic, how much they both can grow.
Maintainability is something subjective which I have to say. In a business world, code is subject to change as new requirements come in every day (expectedly). Procedural style coding might seem lengthy but it does not hide too much (object-oriented is a black-box). Object-oriented style coding is not unnecessary but not overly-designed and should be discouraged when you are working on something that is established or recognized by a group which you might handover stuffs to.
Your say?
- yc, fowler-ed then rob-ed
2 comments:
You are going to have worlds of maintenance problems with either approach, if those examples are typical. There is nothing particularly object-oriented about that second block, either; if anything, the way you have written breaks the most basic principles of object-orientation by exposing unnecessary details of one layer to the next.
Procedural code has its place, as does proper object orientation. This latter example, that has object-looking code that is decidedly not object oriented, does not.
That wasn't a good example anyway.
The code which I work on actually has interfaces, DAOs, etc. introduced to ease my life (and might not ease others' life who have worked on it previously).
Some said it ain't too naked, too much of black-boxing.
Post a Comment