Re: OO Design induces an existential crisis
- From: Rick Elbers <rick.elbers@xxxxxxxxx>
- Date: Thu, 07 Jul 2005 06:49:24 +0200
Andy,
I am going to try to give you the shortest path in the OO network. Be
a network tracer..:-)
For one thing its very important to know what another poster said more
elegantly: you are not the only one, and lots of OO talk is window
dressing kind of humbug. Every course on oo design that starts out
with UML diagrams misses the points you make.
If you come from a strong c background you have normally at least two
problems:
1) You tend to think functionally instead of goal and object oriented
2) You tend to think bottom up instead of top-down
3) You tend to think that wisdom is in the detail.( oops thats 3)
4) You are a technician who loves syntax details( and 4)
What might help you is to do away with all and every theory about
complete oo design and all kind of syntax details around uml diagrams.
Forget round trip engeneering for a while( or forever if you want).
Start with the basics and get a frim grasp( like: while
(*pDest++=*pSrr++); ) Basics of OO design is that its all about
semantics. OO Design is about localization of responsibilities. Don't
go into any details, decide about responsibility for details! Put the
details themselves on the Todo List.
Just list candidate classes from the domain you are working in for a
project( shouldnt take you more then 1 or 2 hours if you know the
domain). Then be a novell writer: see what you can deal for BEHAVIORAL
responsibilities to your candidate classes. Shouldnt take more then
half a day either.
Now take a few scenarios/use cases/tasks/goals which must be met
in the project and write out the way the classes work together to meet
this requirement. Don't go into details considering frameworks you
use, just mention the classes/ responsibilities to be used with the
responsibilities of your domain classes. Don't even try to mention
methods of the framework classes.
This way you should have something like a first analysis OO model in a
for your project in a day.
Now that you worked out a few scenario's then go to some collegea and
run the thing for him. Take a short discussion about the quality of
the design: do the classes show character and identity, are the
responsibilities in the system nicely divided over the system classes,
are the classes losely coupled, is it clear what every class
encapsulate,etc..ect( here you can use your favorite design pattern
catalogue). Take half a day for this design quality kind of thing and
try to consider afterwards a few alternative designs with pro's/cons..
Stop your design efforts here and try to put the scenario's to work in
the design you made so far. Then from that binary use iterations on
your design-implementation loop. Use refactoring, xp practices etc..
Hope it doesnt obfuscate ...:-)
Rick Elbers
On Wed, 6 Jul 2005 16:24:56 +0000 (UTC), kj <socyl@xxxxxxxxxxxxxxxxx>
wrote:
>
>
>I have been programming (mostly procedural stuff) for almost 15
>years. I enjoy programming, take it seriously, and by general
>estimation I am quite good at what I do.
>
>Of these 15 years, I have spent about 7 years trying to train myself
>to do OO programming. I have no problem with *using* pre-existing
>classes, and even extending them. Similarly, I am comfortable with
>the *principles* of OO design. I have studied the GoF book carefully,
>as well as other less famous books on OO design.
>
>Still, when it comes to OO *design* I absolutely *suck*. I takes
>me so long to design anything that I often abandon projects for
>lack of time or loss of interest. Even when I complete a project
>involving OO design, the outcome is puny and incommesurate with
>the enormous effort invested. I often wonder whether the promise
>of future time savings (from ease of maintenance and refactoring)
>are paid for many times over by the *huge* amount of time and sweat
>that I have to put into my design phase.
>
>I am so bad at this that I am seriously wondering what on earth
>I'm doing in this line of work. As OO programming becomes more
>widespread I find myself more and more in the bizarre situation of
>being in a profession for which I have no aptitude whatsoever.
>I'm like the proverbial silent film actor witnessing the birth of
>the talkies. I seriously wonder if it's time for me to start
>thinking of a different line of work...
>
>My question is: how normal is this? Is OO design as horribly
>difficult as I find it? Or are there people who pick it up as
>easily as I picked up C, say? (I was up-to-speed with C in a few
>weeks; similarly for every other computer language I have taught
>myself.) Is there a turning point when one finally "gets" OO
>design? Should I consider some form of apprenticeship or internship
>to learn from experts? (I've exhausted the book route, and I doubt
>that classes will help, since I think my problem is not one of
>understanding principles, but rather of applying them to real-world
>programming tasks.)
>
>I'd very much appreciate your thoughts on this.
>
>kj
.
- Follow-Ups:
- References:
- Prev by Date: Re: OOP/OOD Philosophy
- Next by Date: Re: OO Design induces an existential crisis
- Previous by thread: Re: OO Design induces an existential crisis
- Next by thread: Re: OO Design induces an existential crisis
- Index(es):
Relevant Pages
|
