Re: reduce redundant code

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Schmidt" <sss@xxxxxxxxx> wrote in message
news:OSg34NFhIHA.1168@xxxxxxxxxxxxxxxxxxxxxxx

"Ralph" <nt_consulting64@xxxxxxxxx> schrieb im Newsbeitrag
news:uiip1f$gIHA.748@xxxxxxxxxxxxxxxxxxxxxxx

No, seriously - I always try to implement something
in the procedural way first, ...

...I disagree with this advice.

The "advise" was not thought as strict as it sounds -
I also like the "Pen & Paper-approach" *before* you
write any code.
Just wanted to keep up the flag a bit regarding procedural
coding - it is not "evil" or "bad style" - many (maybe most)
of the FOSS-libraries out there (which in sum can make up
an entire OS + Desktop-Environment) are coded in C - and
offer a very clean procedural API (even the Win-API is
mostly procedural) - so there is nothing wrong with going
that route IMO.
And of course "pure OOP" has also its charme - but many
OO-Patterns are not suited very well for VB-Classic, because
of its lack of inheritance and also because of its relative big
Classes and the relative high Create- and Destroy-Times.
So what I wanted to say was - try to find a good mix between
procedural thinking and the OO-features VB-Classic has to
offer. Many OO-Patterns can be adapted very well - but some
of them can lead to a decrease in performance and an
increase in resources - and some of them are impossible
to implement in VB-Classic.

Back in the day when I started out (Booch and UML 0.9)
I blurted out pretty much the same frustration - "How
do you know when you get it?" The reply I remember and
pass on to my students to this day - "When you have trouble
doing it any other way". <g>
Yep, nothing wrong with that, my "too many books?"-question
was more meant in the sense of: "too many books in the last week".
Reading is a must - but there is always the "effect" after
"assimilating a huge amount of new information", that you
are more confused than before - but that effect usually goes
away after some weeks where the new infos are really trickling
into your mind whilst sleeping. :-)

If one is trying to learn OO/OOPL starting out with a procedural
approach in order to implement something is not a good way
to start. It tends to put the "how" in front of the "what" and
leads to confusion.
From a theoretical point of view this is right - analyze your
problem on paper - find the correct and "normalized" hierarchy,
find the correct patterns - and finally implement.
But that approach is IMO only possible for real experts
(who maybe not even need the paper) and which also have a
"practical background", to avoid the usual pitfalls - and for
languages, which fully support all OO-Patterns.

From my practical background in VB-Classic - I always find
it useful, to have a prototype working really fast, not the
full functionality, but the principle using some small simulated
test-data should be there.
First iteration: to give this prototype a better (Class-)
structure.
Now the fleshout with the real functionality and the real
Data - performancetests.
Another iteration regarding optimizing the structure -
no need to rewrite that much - that is only a rearranging
of already existing Methods - Refactoring, if you want
to call it so.

Don't know where I read this Sig, but it covers this
process very good:
"My most productive day in programming was, to throw
away 1000 lines of code".
;-)

... just define the objects and relationships. Keep it simple,
who 'is a', who 'has a', who 'uses', ... Use a yellow pad,
index cards, whiteboard (my favorite), tinker toys, ...
Yep, nothing wrong with that, but keep your "target-platform"
(VB-Classic) in mind - it is a very good RAD-tool and
you can "prototype" in it nearly as fast as on a whiteboard. ;-)

The implementation will come naturely - but later. <g>
That has always sounded somewhat strict to me -
and consultants (often with no real practical background)
seem to love this sentence - no offense here ;-) ... (since
I know you have done enough coding).
But it implies, that your witheboard-plan is nearly perfect
("...Heh, I made a plan over some days/weeks of intensive
thinking - so this is wellthought and shouldn't be changed
in the implementation-process").
There are examples here in germany, where they exactly
followed that route - large software projects, planned
by wellknown consulting-firms, implemented by other
firms following "the plan" - and the result was mostly a
huge desaster.

Finally one has always to find his own balance between
skill-level, the available tools and "the plan".

Some thoughts/rules which work for me:

Planning on paper *is* good - but there is never
"the perfect plan".

Learning is a must - but don't try to work above your
(current) skill-level.

Everyone "loves" his own code - but don't hesitate,
to throw it away if you find a better solution - work
with iterations, beginning with the "principle", so that
"throwing away code" is not that "costly" (Xtreme-
Programming-approaches worth reading).

OOP and patterns are good - but procedural approaches
are too - try to find a good mix, especially if you work
in a language as VB-Classic.

Components are always good - try to find good encapsulations,
which isolate the different aspects of your problem - but
try to keep their public interfaces as small as possible
(just check the rate of Private/Friend compared with Public
inside your classes - the amount of Publics should be as
low as possible).

Always implement Components in separate Test-Projects -
with their own iteration-cycles to pass, before you try
to "integrate".

A bit "longwinded", but just my 2 Cents... ;-)

Olaf


Perhaps longwinded but correct.
It illustrates that the entire process is nothing if not iterative. I call
it "zooming". You back out to 10,000 feet - piddle with the blocks - then
zoom back in to piddle with a block - then zoom back out, ... <g>

I, (like most that routinely give advice <g>), often violate my own 'rules'.
For example, one of the reasons I got into VB was because of its RAD ability
to create front-ends. I found out early on that getting the 'visual' and
'navigation' features of a front-end agreed to and signed off on, "up-front"
(pun intended), went a long way to insuring a successful delivery.

VB is also very useful in laying out the general architecture or structure
of an application or an application/component suite without giving a damn
where everything is eventually going to be massaged. <g>

-ralph


.

Relevant Pages

  • Re: reduce redundant code
    ... OO-Patterns are not suited very well for VB-Classic, ... First iteration: to give this prototype a better ... I made a plan over some days/weeks of intensive ... inside your classes - the amount of Publics should be as ...
    (microsoft.public.vb.general.discussion)
  • Re: With Agile methods, we are measuring the right things
    ... plan several long waterfall iterations ... track the % done in each iteration ... How much float is in your schedule? ... It's amazing how "float", the security blanket of the traditional system, ...
    (comp.object)
  • Re: What is Java extreme programming?
    ... design so that every iteration ends with an application that has fully working and tested features. ... As XP employs evolutionary design techniques the cost of change is low. ... Adapting the Plan rather than following the plan. ... We only plan in detail the iteration we are about to start. ...
    (comp.lang.java.programmer)
  • Re: What is Java extreme programming?
    ... design so that every iteration ends with an application that has fully working and tested features. ... As XP employs evolutionary design techniques the cost of change is low. ... Adapting the Plan rather than following the plan. ... We only plan in detail the iteration we are about to start. ...
    (comp.lang.java.programmer)
  • Re: finding height of a BST by iteration
    ... BST by iteration. ... You haven't been listening to the advice you got. ...
    (comp.programming)