Hani Suleiman weighs in on "The Black Art of Good Design," doing the needful as usual in saying that good design is a lot more rare than people seem to think, and implying that perhaps describing what good design is is even harder than designing well.
- Posted by: Joseph Ottinger
- Posted on: September 14 2005 15:31 EDT
Answer: If there's no duplicated code, the design is great.
There are gray areas - code that is nearly identical, but some static strings are different, or a different variable is used. These take away from the greatness of the design too, just not as much as literally duplicated code.
A) I am completely serious
B) I've never had the pleasure of working with great, or even good, code. :-(
Answer: If there's no duplicated code, the design is great.There are gray areas - code that is nearly identical, but some static strings are different, or a different variable is used. These take away from the greatness of the design too, just not as much as literally duplicated code.disclaimer:A) I am completely seriousB) I've never had the pleasure of working with great, or even good, code. :-(
Duplicated code is an implementation issue more than a design issue. I really don't think this is a metric of good design. I'd say that almost no duplicated code is a prerequisite of good code but not much more than that.
For example, I can take a good design and implementation with no duplciated code and then screw it up by reversing hierarchies and make it bad with 0 duplicated code.
I think the premise of the blog is correct. Design is an art. Object measures of art are hard to come by.
I think this is a question to be answered by a profesor of some great University.... haha..
I would agree on less code duplication, but this is more an implentation issue.
Its true that you could also learn how to make better designs from having learnt past coding/implentation mistakes.
From my current experience I would say, a good design needs to first meet the requirements. If you don't know precisely what your designing its no good.
Its should handle error(s) with grace / or foresee it.
Be as abstract as possible. (Starting from one level going down to more detail untill implentation detail is reached)
Every good design depends also slightly(if not alot) on the techniques used, and your knowledge or those techniques, whether everything is done in flow charts, UML ect.
I like to design so that each design is loosly coupled to the next one. i.e. If the application needs change its mustn't mean re-drawing serveral diagrams, but then again keeping it as abstract as possible would make it easyer to change certain aspects by choosing the correct level at which the design must be changed.
The worst designs are the ones which were drawn up 1 day and then programmed the next. A design inorder to be good should go through a process of re-designig untill absolute abstraction is reached at any level, i.e. only the entities and flows needed for a certain process/use-case should be in a certain diagram.
If any good programmer can read your designs and understand what the program should do at each stage, I would consider that a good desing (at the very least understanable and therefore easyer to maintain)