Re: My First C# (warning - long post)


"andrewmcdonagh" <andrewmcdonagh@xxxxxxxxx> wrote in message
news:1170954277.185118.185740@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Feb 8, 1:27 am, LX-i <lxi0...@xxxxxxxxxxxx> wrote:

snipped...

That's definitely what I was looking for. :) Thanks again for breaking
it down for me.

My pleasure...

(Did you look at the "second C#" post - and if so, does it look like I'm
on the right track?)

I've given it a quick scan but will need to have another look before
commenting. Might be worth while you posting an update ...but if we
can keep it in this thread, it will help keep the topic focused and
together.

The one main OO design point that you should eventually spot from
where I'm taking you, is that numerous small classes with a single
responsibility, when working together, can create a very simple but
powerful design, with lots of code reuse.

As a top of head metric, my designs tend to consist of 40% of classes
containing a single method, which is no longer than a dozen lines of
code. Another 55% would contain at most 6 methods, with the remaining
5% of classes having more than 6 methods.

The 95% classes would having methods of no more than a dozen lines
and all hold onto the **Single Responsibility Principle. The last 5%
would be 'dodgy' and need refactoring...but then lifes too short and
we do have to actually ship stuff!

Regards

Andrew
** Single Responsibility Principle - http://www.objectmentor.com/
resources/articles/srp.pdf


I can't tell you what a relief it was to read these articles :-)

For some time now I have been trying to explain that an OO approach removes
the need for source code maintenance in the traditional sense. Classes and
methods should be encapsulated and "do what they do". When change is
required it should be new interfaces or extensions and NOT an internal
change to already working code. Apart from the obvious benefit of NOT
requiring regression testing, this approach also simplifies maintaining
applications. I came to learn this by working with COM component development
over a number of years.

Most people here, coming from a procedural background where the whole point
of good coding practice is to ensure that source code is easily maintained,
and one of the reasons for using COBOL in the first place is its
"self-documenting" nature, simply thought I was crazy.

Write applications then don't change the code? Impossible!

Of course, it isn't impossible and I've been doing it for some years now. I
see it as one of the most compelling arguments for using OO.

After a number of clumsy attempts to explain myself, I simply gave up...
It's like trying to explain the concept of "red" to a person who has been
blind since birth...

I have never studied the computer science covered in these articles, but
arrived at the same conclusions just by empirical practice.

This is the first tme I have seen some of the things I know innately,
expressed in a tangible and easily assimilable form. OK, there is a heap of
new jargon and acronyms, but the pure light of the underlying principles
shines through like a beacon.

I strongly recommend any COBOL programmer who is labouring under the burden
of heavy regression testing to at least browse the first article. (I
especially liked his description of "software rot" and what causes it :-))
Here is a direct link:

http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

For me, the quote of the week is:

"The Open Closed Principle (OCP)

A module should be open for extension but closed for modification.

Of all the principles of object oriented design, this is the most important.
It originated
from the work of Bertrand Meyer. It means simply this: We should write our
modules
so that they can be extended, without requiring them to be modified. In
other
words, we want to be able to change what the modules do, without changing
the
source code of the modules."

Now, I wish I'd thought of that... :-)

Pete.


.

Relevant Pages

  • Re: XP Requirement Analysis?
    ... When an existing design needs to be encoded via TDD, ... could have generated the TDD principle. ... The interface _does_ come first. ... to buy a business value. ...
    (comp.object)
  • Re: My First C# (warning - long post)
    ... In several IBM mainframe shops (which is what I knew best in those ... move to many classes with small method applications. ... The one main OO design point that you should eventually spot from ... and all hold onto the **Single Responsibility Principle. ...
    (comp.lang.cobol)
  • Re: CPU recommendations?
    ... done well, classes, templates, and stronger typing can give you a better development environment (clearer and safer source code and at least as small and fast object code). ... C has so many design faults there is no space to list them here. ... inheritance will make an AVR run like an 8051, and multiple inheritance will turn your source code into Greek). ...
    (comp.arch.embedded)
  • Re: ADT Pro With Windows 7 (64-Bit)
    ... application requiring more raw grunt passed us by ... ... just replicating more cores on a single chip. ... difficult--especially given power limitations. ... "The wastebasket is our most important design ...
    (comp.sys.apple2)
  • Re: which object orient language is most suitable for embedded programming?
    ... term operation, ... Well, perhaps, but do I really need the system to allocate anything at run time if it can just as easily be done at compile time ?. ... "The Open Closed Principle" ... Many programmers still view OO design as being overcomplicated and it can be difficult to convince management of the benefits in terms of readability, maintenance, reuse etc. ...
    (comp.arch.embedded)