How to give a mature module design.

B

Buzz Lightyear

Hi, guys,
I have a question tangling me for a very long time.

First day I give a design for a module, and well defined interface,
also I am satisfied with it.
Second day, I *suddenly* found there are one or more cases that hasn't
been considered, then the design and its interfaces need to be
modified. Sometimes, the modification was huge.
And the efficiency is low.

How to improve kinds of this capability for giving a better, well-
formed, mature module design?
Lack of design experience, or C++ skills? I think knowing well of
design patterns is not the root cause.
What's the best practice of it.
Or, is there some document or book can give me a sting, and make me
have a clear thought to the next step.

Thanks.
 
A

aaragon

Hi, guys,
I have a question tangling me for a very long time.

First day I give a design for a module,  and well defined interface,
also I am satisfied with it.
Second day, I *suddenly* found there are one or more cases that hasn't
been considered, then the design and its interfaces need to be
modified. Sometimes, the modification was huge.
And the efficiency is low.

How to improve kinds of this capability for giving a better, well-
formed, mature module design?
Lack of design experience, or C++ skills? I think knowing well of
design patterns is not the root cause.
What's the best practice of it.
Or, is there some document or book can give me a sting, and make me
have a clear thought to the next step.

Thanks.

If you have a well defined structure that you don't modify much, the
best way to add functions to your interface is using the visitor
design pattern. Take a look at the book on design patterns (GoF).
Also, I believe Alexandrescu's approach in Modern C++ Design is better
(he defines both cyclic and acyclic visitors).

aa
 
B

Bart van Ingen Schenau

Hi, guys,
I have a question tangling me for a very long time.

First day I give a design for a module,  and well defined interface,
also I am satisfied with it.
Second day, I *suddenly* found there are one or more cases that hasn't
been considered, then the design and its interfaces need to be
modified. Sometimes, the modification was huge.
And the efficiency is low.

How to improve kinds of this capability for giving a better, well-
formed, mature module design?
Lack of design experience, or C++ skills? I think knowing well of
design patterns is not the root cause.
What's the best practice of it.
Or, is there some document or book can give me a sting, and make me
have a clear thought to the next step.

Thanks.

This definitely sounds like a lack of design experience. The only way
to remedy that is just doing it often and getting feedback. :)

And it also depends a bit on the reason for the design changes.
If the reason is that the customer changed the requirements, there is
very little you can do to protect against it.
If the reason is that you get a better understanding of the
requirements or that you simply overlooked something, then it is best
to discuss your design with colleagues before deciding it is finished.
This can be done in an informal meeting or with a formal review.
Be sure to make it clear that you will not be offended by criticism
and be prepared to get so many comments that you are not able to find
the original design that was drawn on the same sheet.

Bart v Ingen Schenau
 
I

Ian Collins

Paavo said:
Meanwhile, don't be so afraid of refactoring. If a component or subsystem
happens to be badly designed, then the best remedy is to redesign it.
However, you will certainly need unit tests or something equivalent, to
ensure that the thing still works after refactoring. If you have solid unit
tests, you should not be afraid of massive refactoring. This will save you
more time in the future by not having to maintain suboptimal code.

"massive refactoring" is an oxymoron.

A refactoring is a small change, a big change is a redesign!
 
J

James Kanze

"massive refactoring" is an oxymoron.
A refactoring is a small change, a big change is a redesign!

Except that I fear "refactoring" has become one of those "in"
words, that everyone used to describe what they're doing,
regardless of what they're doing. It sounds better to say that
you're refactoring than to say you screwed up the
design---refactoring is good, screwing up isn't:).
 
G

guidolift

Except that I fear "refactoring" has become one of those "in"
words, that everyone used to describe what they're doing,
regardless of what they're doing.  It sounds better to say that
you're refactoring than to say you screwed up the
design---refactoring is good, screwing up isn't:).

--
James Kanze (GABI Software)             email:[email protected]
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Is there any nice books to help this kind of capability, although it
depends much on the experience. :)
 
N

Noah Roberts

Ian said:
"massive refactoring" is an oxymoron.

A refactoring is a small change, a big change is a redesign!

They probably mean to invoke the "refactor mercilessly" idiom.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top