Re: OODesign - OPF, design pattern

The truth is, that once you have written an adapter framework for your favourite widget set, you have written it once and for all; it gets used over and over again. Having been tested thoroughly, the framework will need very little alteration or maintenance.

I might believe this if I thought that such frameworks can ever be
contained. From what I've seen in real world, it seems to me that OO
frameworks are a never-finished story.

Not actually limited to adapter classes, but the thing that bothers me
the most is that there are always features that would be easy and
straight-forward to implement in a conventional way, but they require
non-trivial amount of work on the framework itself to make them
integrated in what you call "the background". Transaction handling is
one such example of a very important feature that usually gets left out
in initial design of an OPF framework.

If you count the frameworks as part of the application then, yes such apps will seem hfty. But if you realise that the framework is not intended to be used just for the one application, and that it can be used for many more apps, without modification, then the app shrinks in size as the framework is considered to be external to it.

People I know have a habit of redesigning their frameworks at least to
some degree for every new application they use it in. And I can
understand that, because I do believe that there's rarely (if ever)
a single size that fits all.
After all, if there was one all-encompassing OO framework out there,
wouldn't every OO supporter be using it? Why are there so many people
writing their own? I think this has a lot to do with the notion of
boredom over the conventional ways of software design. It's a big
challenge, and that's what's driving enthusiastic developers. In other
words, it's the journey, not the goal, that matters. Anyone who has
ever even attempted to write an OO framework of any kind probably
learned a great deal from that experience. But with a serious project
ahead of you, I don't think it's appropriate to be learning things as
you go.

OPFs are but a small part of OO design. Their purpose is to separate out database differences from the object model; that is all, period.

Yes, I realize I've been using mixed terms. I'm otherwise aware of the
difference. But I also see similarity here with the conventional model!
Different parts of an OO framework are pretty much subject to its OPF
model, the same way that traditional form-based design is usually
subject to the database model. IOW, you need to design BOs in a specific
way to allow for proper streaming by the OPF. I may be wrong, but that's
how I see it.

Saying that most develpoers are not writing OO code is not an insult, it is a simple statement of fact that most jobs get pushed into existence by forces outside the developers' control using a RAD, "OOish" IDE where everything gets slammed on the form because "that's the way it works" :-(

Ah, here's where I radically disagree with you. :)
I don't feel any pressure from the IDE to design my code in a particular
way. As a matter of fact, I seldom implement a dialog by writing all
of the code in the same file. Usually, I make a couple of separate code
files, where I design my BOs and the objects that manage them, then link
to everything from the form's code file. Sometimes the majority of the
code that is linked to a single dialog actually resides in completely
separate code files.

But yes, all the controls usually do get put on the form and are not
instantiated dynamically by some mediating layer. I prefer this approach
because it gives me a central point of reference to everything UI.

It's called feature creep and has to be monitored very carefully.

While I don't disagree, I think it's very difficult to avoid it and
it's best to plan for it. This is what I said on the last staff meeting
at my office, when we were discussing the v2.0 of our product:

"I'd much rather accept a strategical decision not to implement a
certain feature, than be forced into it by the limits of our design."

From a quick thought about this kind of problem, I would say that it is a case, not of overuse of frameworks, but maybe, overuse of notifications :-)

May very well be. <g>

We don't use the Observer pattern that much; its main purpose in our frameworks is to keep UI controls up to date with business models, although we do use it in limited other places.

I find the BO<->UI syncronization to be the biggest pain in this regard.
In any non-trivial interface there's a whole lot of synchronizing going
on. The example I was talking about was a kind of an IDE application -
with property inspector and a tree of objects that were linked to one
another much the same way that all the component on a Delphi form are.

Markedly, not all applications are built like that, so I guess it's not
an inherent problem but rather a potential one.

Which is why you need to develop *and* test classes before integration, preferably using unit testing to allow you to easily check for regression if you do have to add an unforeseen feature. One unit test can save days of heartache :-)

Ough! Unit testing is another pet peeve of mine. I firmly believe that
it's good for testing predictable self-contained parts of code, like
algorithms, where you need to really make sure that outputs match the
inputs. But I think that using a unit test for every class you ever
write is a bit over board. With even slightly changing requirements
it quickly becomes a maintenance pain.

emperor's (relatively) new clothes.

Except that OO is not new, it has been around for decades in one form or another.

Well, I'm not so sure. Object oriented languages have been around that long, yes. But OO programming in its true sense only really took of when
XP and similar techniques started sprouting up and "OO" became a
buzzword. And that wasn't too long ago...

IMO, there is no such thing as extreme OO, the .NET framework is designed with everything being an object and is a stunning example of a fairly well designed framework that stands up to reuse very well indeed.

IMO, having everything in objects is not the same as having an OO
framework. Not anymore, that is. That's why I made the distinction about
the new synonym that "OO" has become.

..NET doesn't get in my way of building applictions the way I feel most
comfortable. If I wanted to (which I don't!), I could still shove the
whole application code into a single .cs file. Using frameworks like
yours (<disclaimer>which I know close to nothing about</disclaimer>) I
probably won't be able to do that.

As for reuse, I agree that it's absolutely critical. But I have serious
doubts about any OO framework being ever completely reusable. Parts of
it, yes. Especially if decoupled properly. But I can already achieve the
same by adehering to the conventional approach, and with less code.

I should add that I understand why .NET is so much more attractive to
OO framework designers, like yourself - every OO framework (and
especially its OPF parts) require heavy runtime information about the
types that are being dynamically generated. And Reflection is miles
ahead of RTTI in this regard.

But this is exactly what reminds me of the times when we were all using
(and hating) late binding of IDispatch and the like. It's different now,
but it's still late binding. If something goes awry, chances are you
won't find out until runtime. And hence, the unit testing. :)

Joanna, let me say I appreciate your non-intrusive style of standing up
for your beliefs. IMO, that's the best kind of conversation. :)

--
Regards,
Aleksander Oven
.

Relevant Pages

  • Re: OODesign - OPF, design pattern
    ... What I had in mind were very specific design patterns, ... It's under their control, for goodness ... but once I had reached a point where I could stop "tweaking" the framework to handle scenarios that I hadn't previously thought of the development time suddenly increased dramatically. ... once you zoom in even just a little, OO design reveals more layers. ...
    (borland.public.delphi.non-technical)
  • Re: Updating vb6/vba knowledge - too late to teach old dog new tricks?
    ... is a programming paradigm that uses "objects" and their interactions to design applications and computer programs. ... What is Unified Modeling Language? ... LINQ is a Microsoft .NET Framework component that adds native data querying capabilities to .NET languages. ... Microsoft LINQ defines a set of query operators that can be used to query, project and filter data in arrays, enumerable classes, XML, relational database, and third party data sources. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Model Check Inside - Out
    ... The use of design patterns make your application ... encapsulate operations to eliminate dependencies on specific operations. ... For example, a framework ...
    (comp.lang.misc)
  • Re: The structure of PHP/Web Application coding.
    ... From your mentioning of Design Patterns i assume you want to/are practicing OOP. ... Refactoring should start allmost immediately from the start of any project and is to be done so frequently that it comes close to being done "all te time". ... IMHO a framework is simply the outcome of applying the principles of XP over the development of several similar applications. ...
    (comp.lang.php)
  • Re: OODesign - OPF, design pattern
    ... What constantly kept getting in my way was the fact, that UI controls ... is exactly what it takes - writing wrappers and reinventing. ... The truth is, that once you have written an adapter framework for your favourite widget set, you have written it once and for all; it gets used over and over again. ... OPFs are but a small part of OO design. ...
    (borland.public.delphi.non-technical)