Re: OODesign - OPF, design pattern

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.

Remember, don't confuse the concept with the implementation. A few of us
have different implementations but generally they all do a similar thing,
they let us develop applications in a more abstract way. This lets us
develop in small isolated pieces of code which may be tested individually,
and also talk about "things" in our app in a general way such as "this
object should create email notifications, and will provide the email address
+ subject + text to send".



O..M..G!

How on earth is this simplifying application development?

I developed a Pocket PC app last year using the compact framework. The
majority of the work was originally supposed to be done on a computer, where
information would be entered from paper work recorded during the day. One
day I was told the plan had changed and now most of the work would be done
on an Intermec. Now I could have gone down the route of just having lots of
forms available from menus. A competitor took this approach and the
customer thought that it was too complicated. So I set about writing a task
oriented framework which would

A: Guide the user through options that are availble at a certain point.
E.G. if you are in a customer site then you can sell something to a
customer.
B: Allow me to reuse certain tasks from any point in the system. E.G.
printing an invoice is done at the end of delivering an order, can be
reprinted at any point during the visit, or can even be reprinted back at
the depot.
C: Allow me to reuse GUI. E.G. the user very often "selects an object from
this list" or "captures the customer's signaure".

It took a few months to write, especially as I also had to write my own OPF
too, but it was definitely worth it! My boss moaned a bit "if this is a
quick way to write apps why is it taking so long?" 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. Now whenever the user wants a new step in a process, or a new
task, or a task to be made available from somewhere else it takes hardly any
time at all. *Now* he is very happy about it :-) Ofcourse I don't have to
develop it again. If ever we write another task oriented app for the PPC it
will be much quicker.


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.

I think it is definitely more work in Win32 than it is in .NET.
Additionally, at first I find it quite slow, but once you know how your code
looks you can use something like ModelMaker and then write a code-gen hook
to emit additional code based on diagrams etc. I have a code-gen plugin
that generates all of the framework members for my properties and
associations. For example

private MultiRole<OrderLine> M_Lines;
public OrderLine Lines
{
get { return M_Lines; }
}

and also the construction of those members

M_Lines = new MultiRole<OrderLine>("Lines", "Order", DeleteAction.Cascade);

Something like that anyway, I'd have to look at the code :-)


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!

Why? The most simple way I think is to do this

<GUI>
<Object types the GUI uses>
<Application API>
<Database>

OPF can make things simple, but as long as the app talks to the data via an
application API of some kind you will get benefits from that. How you
implement it is completely up to you.


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.

Your middle-man could take the form of a TDataSet.


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.

I never use interfaces to reference count. I've never seen an approach I
really like. If your objects get/set their values from a central cache then
you can easily record a "date last used" and unload objects not touched for
X amount of time (as long as they have not been modified). If an instance
of an object still exists it doesn't matter, because reading a property of
the object would simply reload the cache from the DB.


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.

Or go with the TDataSet wrapper ofcourse :-) ECO IV has a VCL.NET wrapper
now, its a good example of how this can work. It'd be really interesting to
see if it would be possible to get this working in a Win32 TDataSet via
interop.


And as I've gathered from OO-experts' posts on numerous occasions, this
is exactly what it takes - writing wrappers and reinventing.

I've never written wrappers. I either databding (ECO) or my composite GUI
control knows how to display the request object and also how to set the
response values (my compact framework app).


I guess it's not unusual to see OO-experts writing their own TEdit and
TButton implementations.

I've never done that.



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 imagine it can be a lot of work, yes. The benefit I suppose is that you
only ever have to do it once. It's not something I've ever had to do
though.


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

My PPC one isn't.

BusinessClasses.dll - 90% auto generated by ModelMaker class diagrams
TaskFlow.dll - 100% hand written, I really should get around to writing a
code-gen for this too, to generate from activity diagrams
GUI.dll - Components dropped onto a CustomControl in the designer, with a
little bit of code to show some values on the screen etc.

That's it. They are tied together by DLLs I can reuse
GuiFactory.dll - Returns a composite control that identifies itself as the
object to handle objects of a certain type, e.g. AuthenticateUserParameters.
TaskExecutor.dll - Basic "Task" framework containing classes that
TaskFlow.dll uses as ancestors.
PersistenceFramework.dll - Loads / saves object instances. You could use
static methods on a class to fetch/update data though.


* 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".

Nah. I do plenty of OOP that is nothing to do with OPF.


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.

OPF just utilises OOP. If you write OOP then you are writing OOP :-)


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

Maybe my design is just very simple then, because whenever someone asks me
for a new feature I just grin and say "Okay". For example, at the moment I
have a 3 stage process when the customer wants to buy adhoc goods from a
visiting employee

01: Employe enters details of what the customer wants to buy, this creates
the order.
02: Employee then enters details of what they delivered, this creates a
delivery note or invoice (depending on the account type).
03: Employee then potentially records goods returned from a previous
delivery.

This is going to be changed so that now the task looks at open orders +
recent deliveries and shows the following

Brand Qty delivered Qty returned Qty on order

From this I can manage all 3 at the same time, it's much more simple for the
user, and it saves a lot of time too.


I'm looking forward to it, and its in the application layer not the business
objects layer. I wont have a "ThreeInOneOrder" class or anything, just a
new task in the app layer that I will execute instead of the existing ones.


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!

Or locked in by an over complicated design maybe?

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...

I don't use interfaces that much. I do use them, but I do use them when I
feel I need them. You could always have them all implement an IAsObject
interface with the following

function GetAsObject: TObject;

Then you can grab the object itself for debugging purposes.

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.

I really don't know what you are talking about here, I've never experienced
such a thing. Maybe the problem is that you are trying to throw in as many
design patterns as you possibly can? I use very few design patterns, and
with multi-cast events in .NET I use one less :-)


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.

It's only that case if it is pointless. For you it may be pointless, but
for others it isn't :-) I still write some "procedural" type apps too you
know. Something I am writing now uses an OPF but still does quite a lot of
"code in forms". Am I proud of that? Nope. Does it bother me? Nope. If
the app starts to get too big then I will ask for time to write it
differently.


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.

My PPC app took 1 year to write. This includes the OPF, the task layer, and
the app + gui + exchange with the back office. I was the only person
working on it. In contrast the back office took about 2 years, had a team
of about 5 or 6 people working on it, and probably only does about 50% more
stuff. In addition to this it is far easier to add features to my app
without them screwing something else up. So I disagree, my app certainly
did reach production state. I'd never written an app layer or a task
framework before, I just felt that this app needed one, and I am glad I
stuck with it!


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

At least a year, you'd have to write your "blog writing framework" first :-)



.