This is one reason why a good design layout is important, probably with UML. You can view the complete design at once and immediately see how each class relates to the others, all in one diagram. No need to jump between a bunch of files.

I've yet to see a UML diagram that indicates where the bugs are.

Abigail

I wasn't talking about the situation where you proudly show your design in a conference room using a spiffy powerpoint presentation.

Nor was I. I was addressing the point that heavy OO is hard to work through because the complete design is scattered throughout a large number of files. UML helps here because even a crappy design will at least show all the crap in one place, provided the code matches what is in that diagram.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

You are partially right. UML does provide a nifty design file, but it does not proclude the creation of architectures that have dependencies on thousands of objects, evil beasts that require jumping through 15 methods to achieve reality.

Note about UML -- Many times, though, UML is generated after-the-fact (from code using Rational's software) and in absense of actual design, planning, and API/design documentation. And this is encouraged in the industry. So when design is no longer a seperate step, it ceases to be design. Personally, I do design on whiteboards and with pencils, translate later, and if you start with UML you have already started too low-level. I like to work down from modular components that each have seperate purposes. The insides of those modules can be designed once their behavior and interfaces are defined, but mainly I care first about how the system acts, and what it is. Is it primarly an event loop, etc? I don't care if there is a SuperConductingEventLoopManagerDelegate, for instance. That's way too low level for the design phase.

All of these processes (well, maybe not UML) are important everywhere, regardless of programming language, when projects rise about simple-helper-script level. I see a lot of UML thrown together at random, essentially boxes and arrows, and folks tend to call that a design. Well, no, a design is only such when you have a *good* configuration of boxes and arrows.

As a final point, it's wise to note that Sun itself is guilty of the file-jumping I speak of. See how many pages of the J2SDK documentations you have to read to fully understand a particular method call. The calls and dependancies fly absolutely all over the place.

If anything, if neglect of Perl side leads to obfuscation through compaction, Java leads to obfuscation through expansion and objects will multiply like rabbits. Is there a moral here? Nope. Just watch out for dragons.

When was in college, I wanted to be a Software Architect. Java, in fact, was something I liked. Then, somehow, it scared me...I still love software design, and I'd do it all day if I could...but I am aware of the dragons of every approach, and even what the industry embraces hardest (Java, UML, XML/SOAP, etc) are only suitable if they can be employed well by those who know they have limitations. Zealots of any particular one-sided approach are the most dangerous foe to good programming. XML everywhere, SOAP everywhere, OO everywhere. Got to pick the best of both worlds...and design should not presume to pick certain tools above others until they can be weighed fairly.

Again, Programming is looked upon as an Engineering Process. That's good, but the rules aren't nearly hard and fast as the physics of bridge design. There is a lot of art there, and a lot of gray areas. Hard and fast rules are often the enemy of innovation, but so are lack of any sort of rules. Yeah, it's a Zen thing.

Ok, I guess I forgot what I was talking about :)

Many times, though, UML is generated after-the-fact (from code using Rational's software) and in absense of actual design, planning, and API/design documentation.

Definately agree here. Such "reverse engineering" of code into a UML diagram is really anti-design. If such tools are used at all, they should only be on old projects that were created without the benifit of a UML (or similar) diagram. If your project has a requirement to generate UML, do it before actual code is written.

See how many pages of the J2SDK documentations you have to read to fully understand a particular method call.

I don't miss the days of having to intilize at least two objects just to read a file line-by-line :)

Java, in fact, was something I liked.

Same here. I was enticed by its clean (though impure) object system. But that blasted API got to me after a while.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated