Re: OODesign - OPF, design pattern

Peter Morris wrote:
<snip>

I've been monitoring oodesign group for years now, and after even
posting a couple of times there (not lately though), I genuinely feel
that you (Peter), Joanna, and many other OO-enthusiasts are true experts
in this field.
And you have to be! Some of the techniques you're using are so advanced
it takes a whole lot of intellect to even grasp the concepts.

But it's after reading posts like this one from Peter, when the only
thing I can say to myself is:

O..M..G!

How on earth is this simplifying application development?

I'm finding OPF enthusiasts everywhere are giving the same reasons why
such approach to application development is beneficial, and I'm really
trying to see it myself, but after all this time I just can't.

Sure, using Observer pattern here and there can really be useful. A
couple of other design patterns are great, too. And I simply couldn't
live without using interfaces to decouple my objects. But designing the
whole application around such decoupled layers? That's just insane!

Let me explain...

A few years back, I tried to implement a small application this way.
What constantly kept getting in my way was the fact, that UI controls
and the RTL and VCL itselves simply aren't built to support
MVP/MVC-style of development. I couldn't use any of the more advanced
components out there, because they were doing too many internal magic
that wasn't exposed to my controller layer. Just handling drag-n'-drop
was almost impossible. And responding to dynamic user input? Forget it!
Tracking the focus changes, intercepting messages, etc. It got really ugly really fast. I ended up having a whole lot of abstration leakage
between the layers and was finding myself constantly having to resort to
hacks to minimize those leaks.

This lead me to believe that MVP/MVC might still be possible in theory,
but with one important sacrifice: you must either stick to the simplest
UI controls and forget about the rich 3rd-party components, or be
prepared to write a whole lot of wrappers and even modify the source
code of many of the controls in order get them to bend to your will.

And as I've gathered from OO-experts' posts on numerous occasions, this
is exactly what it takes - writing wrappers and reinventing.
I guess it's not unusual to see OO-experts writing their own TEdit and
TButton implementations.

And that's the insane part, IMHO. By developing this separate (and yet
strangely tight-coupled) framework you sometimes double and even triple
the amount of code that needs to be written in order to achieve even
the simplest of tasks. And this is not so innocent when it comes to
maintaining all this code.

I haven't yet seen an OO-based* application, that wasn't at least twice
as hefty than its plain counterpart.

* This is actually one of my pet peeves. OO used to mean "Object
Oriented", but nowadays it's more a synonim for "Object Persistence
Framework Oriented". By this definition you could say that most
developers out there (including me) aren't writing OO code. Which is
kind of insulting, when I think of it.

I have first hand experience in what it takes to debug this kind of
applications. The fact that I've designed it myself doesn't help. The
design started as extremely elegant (don't they always?). All business
classes were neatly isloated from the UI, with interfaces published in
separate units as to minimize inter-class dependencies. There were
observers, subjects, aspects, factories, actors, visitors, chains of
command - the whole shabang. All in all, a really nice class framework.
I can't help but still be a little proud of it even today.

But the pride soon fades when I remeber how it started growing in
complexity as I added features. In mature development stages, there are
often some features that weren't anticipated from the start. And this is
where things start to really fall apart. I've seen this happen to
others, too! It's one of the reasons why I'm presently against overuse
of such frameworks - they can quickly turn into ball-n'-chain if you
don't anticipate the unanticipated features. You become locked in by
your own clever design!

Soon, there's a whole lot of notifications flying around all the time,
which give out some seriously loooong call stacks. I don't really mind
the length of the call stack - it's the unreadability that really gets
to me every time. When all the calls look like this (paraphrasing from
memory):

TCommandHandler.FindActor(...);
TAspectAwareObserver.Notify(...);
TAspectAwareObserver.Notify(...);
TAspectAwareSubject.SignalStatus(...);
TAspectAwareObserver.Notify(...);
TAspectAwareSubject.SignalStatus(...);
TAspectAwareObserver.Notify(...);
.....

and it's all interfaces, it's really hard to get additional information
about the actual object that's misbehaving. Before you know it, you need
to write additional code to assist you in debugging. Yeah, more code -
that will help fight complexity...

And then there are the side effects - unforseen interactions between
parts of the program that weren't supposed to affect each other.
It turns out infinite notification loops are all too common when
complexity grows. And there's no definite counter-measures to fight
them, except for iron discipline during development, and - you guessed
it - more code! Checks on every critical entry-point to make sure we
don't end up in a notification cycle of doom.

A couple of days ago, there was a post in this NG, titled "Holding a
program in your head". Well, I'd say you better hold it in your head if
you're doing it OO-style! :)

Seriously, though... This all invariably causes a lot of stress - it's
really hard having to concentrate on so many intricate details almost
all the time. One minute you might be submerged deep into writing
business logic and then the next, you'll be walking up the seemingly
infinite call stack, trying to figure out why that darned label isn't
getting updated with the new caption.

IMO, this violates one of the key principles of software development -
reducing the amount of context switching in your brain. If anything,
this kind of development increases and intensifies those switches!
And I'm sure even experts get annoyed by this sometimes.

I can't help but feel that this extreme OO is just one of the many
variations on the same theme in software industry - emperor's
(relatively) new clothes.

I can't event start to imagine what extra development and maintenance
costs such design infers on an moderate to fairly complex project.
It seems mind-boggling that someone would embark on a 2+ year long
journey of software design and development with serious intentions
to build it entirely on OPF principles. I imagine it would never
reach production stage.

What I've been striving towards in my own development lately is to
reduce the amount of software parts that I personally need to worry
about as much as possible. To treat large parts of the design as
black boxes, so to speak. But I took a different route - I'm not
building vertical frameworks. Instead, I'm distributing my applications
horizontally into smaller, more managable parts (plug-ins).

I'm finding it increasingly easier to distribute such self-contained
mini projects to other developers, because there are relatively small
sets of rules that everyone needs to abide by in order to play together.
On their own, developers have more freedom and may even use OPF
internally, if they really feel so strongly about it, as long as the
public interfaces between the plugins aren't leaking those details to
the outside world.

There's so much more on my mind on this topic and I just remebered I've
got a blog for such rants. But then I just wasted 2 hours writing this
post and I'd need to seriously refactor it before posting it on the
blog. So I'm not going to do it. :P

I wonder how much time it would take me to if I'd have written it using
OO priciples in the first place? :D

--
Regards,
Aleksander Oven
.