Easy to understand and follow OO design.
Has anyone ever found that when they have to fix a simple bug in a large OO application, that so many complex patterns, abstactions, polymorphism, and an excessive numbers of interfaces make the code very difficult to navigate, and that you have to study for hours to get your head around the complete OO design before you can fix what might just be a simple problem?
The application may be a beautiful example of OO design, but really how maintainable is it, in terms of being able to find and fix bugs quickly, without needing to understand the whole app?
Or does my asking this question mean that I'm a mediocre OO programmer?
[649 byte] By [
iain_8a] at [2007-10-3 1:12:41]
Hi iain_8,
I have to say that I agree with in some points.
In my opinion some e-business companies often develope a very large application and use those OO patterns so the applications seem to be well-organized.
But in reality, if there is a problem wich can be solved faster without that OO patterns and MVC-"restrictions", programmers do it for the sake of the their "laziness".
Moreover, not every programmer is a software-designer. So imho you either have to plan your application so good, that programmers are restricted to use those patterns or you used them wrongly.
Probably this was a lot of BLABLA...
Anyway, a big advantage of patterns is that - if you use standards - another company or software-designer, can read more easily even though it seems to be more complex.
But honestly, do you have to maintain every single part of your application.
No otherwise you would rewrite it...
So the main aim of patterns is to split your app up into "readable" pieces.
I am currently working on a small web app. But I have to do a lot of planning and my customer does not know yet which functions he would like to be implemented. So I am forced to work with patterns and MVC otherwise if there was a single change I could rewrite my application
Message was edited by:
Peterson
> Has anyone ever found that when they have to fix a
> simple bug in a large OO application, that so many
> complex patterns, abstactions, polymorphism, and an
> excessive numbers of interfaces make the code very
> difficult to navigate, and that you have to study for
> hours to get your head around the complete OO design
> before you can fix what might just be a simple
> problem?
No. The opposite.
If you need to study the entire design to understand a simple part, it's badly designed, period.
> The application may be a beautiful example of OO
> design, but really how maintainable is it, in terms
> of being able to find and fix bugs quickly, without
> needing to understand the whole app?
If it's really is well designed, the bug will be confined to one class or the interaction between a relatively low number of classes. If it is well developed (regardless of OO-ness) the logging will indicate a lot already and there will be automated tests in place. So it should be a matter of adding acceptance/interaction/unit tests to show and reproduce the error, and then fixing it.
In fact I'd say that if an application is hard to read/navigate/maintain, it is definitely not an example of good (OO) design.
> Or does my asking this question mean that I'm a
> mediocre OO programmer?
It could indeed indicate that you have things to learn. We all do.
It could also mean you have been working on projects that are simply too ill-designed, like a lot of them, and that's why you feel like this. Trust me, if the same developers that made a Java application hard to maintain had been working in, say C, the nightmare would be even worse.
Lokoa at 2007-7-14 18:09:44 >
The biggest single problem I find is trying to trace through the logic flow for some piece of functionality, coming across an interface, and then needing to go right back to the initial configuration and factory class to work out what implementation of the interface is being used. At least Eclipse can give you a clue by finding all the implementers of an interface, but when you have to do this with vi!!!
http://www.phppatterns.com/docs/design/hello_world_in_patterns
> The biggest single problem I find is trying to trace
> through the logic flow for some piece of
> functionality, coming across an interface, and then
> needing to go right back to the initial configuration
> and factory class to work out what implementation of
> the interface is being used.
I run into this issue with a lot of the code I work with now and yes, it can be problematic. I don't think your struggling with it means you are a mediocre programmer.
The issues in the code I deal with are:
A. The abstract factory pattern is overused. This is something that should be done a key abstractions in a program (if necessary.) Not every class should be implemented through the abstract factory pattern.
B. A fundamental misunderstanding of good OO approach. Reading the GoF patterns book without a good grasp on OO principles is very dangerous. What I see in the code I deal with is that there are lots of abstract factories but the actual implementation of most classes is in a procedural style. The actual logic associated with the Object types lives in outside of that type. Also, there are two many breakdowns where you can't follow process flow without looking at two or three classes at once. This is not good OO. Good OO is simple. much simpler (in general) than equivalent procedural code.
> At least Eclipse can
> give you a clue by finding all the implementers of an
> interface, but when you have to do this with vi!!!
I don't know why you are writing java in vi but you should be using a combination of find and egrep to look up the implememtation classes in the source.
> I run into this issue with a lot of the code I work
> with now and yes, it can be problematic. I don't
> think your struggling with it means you are a
> mediocre programmer.
Easy to see if you're using Spring to inject the implementation for that interface. Just look at the application context.
> The issues in the code I deal with are:
>
> A. The abstract factory pattern is overused. This is
> something that should be done a key abstractions in a
> program (if necessary.) Not every class should be
> implemented through the abstract factory pattern.
Amen.
> B. A fundamental misunderstanding of good OO
> approach. Reading the GoF patterns book without a
> good grasp on OO principles is very dangerous. What
> I see in the code I deal with is that there are lots
> of abstract factories but the actual implementation
> of most classes is in a procedural style.
Yes. The Command pattern makes this even worse. One Command per method is the norm is some huge apps I see. The false hope of composing Commands into Composite macros, which never happens, only makes the code too granular and hard to understand.
> The actual
> logic associated with the Object types lives in
> outside of that type. Also, there are two many
> breakdowns where you can't follow process flow
> without looking at two or three classes at once.
> This is not good OO. Good OO is simple. much
> simpler (in general) than equivalent procedural
> code.
I think a lot of "core" J2EE patterns made this worse.
> I don't know why you are writing java in vi but you
> should be using a combination of find and egrep to
> look up the implememtation classes in the source.
vi? Oh, my. Even emacs would be a better choice.
%
> The application may be a beautiful example of OO
> design, but really how maintainable is it, in terms
> of being able to find and fix bugs quickly, without
> needing to understand the whole app?
If it is indeed well-designed, then you should be able to find & fix bugs quickly. Good code is its own best documentation.
If you find it too difficult to understand & maintain, there is the possibility that the app you're looking at, has been over-engineered.
It might be the product of chronic pattern abuse i.e. the belief that the more patterns you use, the better your design.
Unfortunately, a design pattern does not guarantee good design.
I think the main advantage when using the design patterns and principles is to have a flexible application. It is very convenient large applications. I think an application should be structured in such a way that each module can be tested separately.
I think your're saying about finding bugs in a large application that in application based on oo design. I'm pretty sure that an application containing oo design code is more easy to maintain than one without.
http://www.oodesign.com
