New to OO concepts - re-usability

[Phlip]

> x wrote:
> 
>> Hi,
>>
>> I have been reading up on the OO environment, focusing on the use of UML
>> to speed up creation of objects, or even to create superior designs of
>> objects.

You might think you must write UML first, then copy it to code. Whether you 
do this or not isn't as important as whether your code can always get 
better. For example, you could use UML to illustrate its current state, 
upgrade the code, and then use UML to demonstrate to colleagues who re-use 
the code what it now looks like & how it changed. Projects where any of the 
classes never change go downhill and become mired in their legacy 
expectations. Don't do that.

You can't change code without unit tests. They are more important than UML, 
therefor write them before you write code. Then as you write more code, 
"refactor" it to improve its design. (Python's typeless code & pristine 
syntax makes refactoring as easy as falling off a log.)

Long term, for large projects, making sure some "design document" matches 
the current state of the code has been discovered again and again to be a 
pure waste of time. Either the UML locks in a bad design, or the design 
gets better and the UML document does not reflect this.

"Well designed code" is not the same as "code with a lot of pictures 
describing it."

>> Its great. Everyone is creating their reusable objects, no efforts are
>> being wasted, these huge libraries are being built....are they?

No, UML won't do this alone. To write a re-usable library that others can 
use, you should develop it (just as iteratively as one-shot code) with at 
least three client applications all at the same time. That which all three 
find themselves doing belongs inside the library, and "nice to haves" don't.

>> Does everyone create their own libraries, with a little sharing when
>> requested, or is there some huge repository of objects available to all
>> and sundry where the benefits of mankind's OO efforts are being stored
>> nice and neat... you know, like the Human Genome project?

Easy. For every feature you must add, you write test code first and get it 
to fail. Then add the feature until the test code passes. Version this test 
code with the project - don't throw it away - and create a "super_test" 
that calls all the tests in a project. 

All this hacking might just make you think such a project will lead to poor 
design.

Refactor the code each time you see something break the rule 
OnceAndOnlyOnce. That means any concept, no matter how profound or trivial, 
must only appear in source once. As you refactor, re-usable modules grow 
out of the primordial ooze of functionality. And many of these re-usables 
might just appear where you could never have expected them to with all the 
up-front UML in the world.

Now why are unit tests crucial to re-use at all levels of a project? If 
every single feature you write has a unit test, then every feature already 
has two clients, not just one. It has a production client that sends it 
real messages, and it also has a test client sending it test messages. 
Test-first code is all already re-used once. This makes re-using it again 
blazingly easy.

        http://c2.com/cgi/wiki?CodeUnitTestFirst
        http://c2.com/cgi/wiki?RefactorMercilessly

-- 
  Phlip                          phlip_cpp at my-deja.com
============== http://phlip.webjump.com ==============
  --  How does Bugs Bunny do it? How does he know when he
      wakes up in the morning to put in his pocket 3 sticks
      of dynamite, a physician costume, and a bicycle pump?  --