Re: OODesign - OPF, design pattern

As the film, the book is also an implementation of someone's idea. The
book can stink, too. But the concept behind any of those two may indeed
be good, yes.

It was a crap analogy that was merely meant to be a joke. I was saying that
you can't say that 1 thing is bad because something else based on it was
crap.

This logic just doesn't apply here. What am I supposed to do when
someone's feeding me something that is IMO a bad framework, but which
they feel is a superb one?

Same as you should do whenever someone gives you crap code. You should do
something about it.


You're right, it shouldn't. However, imposing the Visitor pattern on the
class won't bring this problem any closer to solution. In both cases you
need to implement a second class that knows how to stream the first one.

So what exactly is then the benefit of doing this:

VisitableCustomer.Accept(StreamingVisitor);

and then having the customer call the visitor back:

procedure TVisitableCustomer.Accept(const aVisitor: IVisitor);
begin
aVisitor.Visit(Self);
end;

over this:

Streamer.WriteObject(Customer);
?

One of the benefits of the visitor pattern is that it enables the visitor
access to stuff that might be private. For example if a HumanBody class has
many organs you should not be able to access those object instances
directly, but when the HumanBody accepts a visitor it can do this

aVisitor.Visit(self);
for Organ in PrivateListOfOrgans do
aVisotor.Visit(Organ);

I'm not arguing, it's just another example. The visitor pattern has its
place, but I wouldn't implement it unless I was performing many different
actions on a structure of classes (say some kind of structured document).
So far I have not had any use. In fact I once went to implement this
pattern on a structure in order to stream it to XML, I just wanted this

<parent name="Fred">
<children>
<child name"John"/>
</children>
</parent>

but to achieve this I had to have

aVisitor.Visit(Self);
for Child in Children do
aVisitor.Visit(Child);
aVisitor.EndVisit(self);

Otherwise I would get no </children>. Having that many methods on my class
was just annoying, so I wrote a single method with for loops :-)


I understand why it may have worked for /you/. But you proposed this
idea to OP, who specifically said that they only develop applications
that aren't that complex.

I didn't prose MY approach. I wanted to put across that an app layer is
probably more important than the OPF layer. I merely mentioned my approach
in one of my apps because I like talking about stuff :-)


http://www.hmrc.gov.uk/employers/employee_leaves.htm

I'm not sure what you meant with this link, sorry.

I didn't think it was that subtle. Someone writes 100 lines of code just to
show the main form of an app? The URL is all about employees leaving a
company. In other words

F I R E D!!!!!!



You're missing the point. You wouldn't have had to type all that code
if you hadn't used the framework in the first place. :)

You are absolustely correct. I would have had to manually spew out
different code instead.



But I might be wrong, since you actually may be developing applications
that can't be made simpler code-wise. What I am sure about is that there
are many who do it just to entertain themselves.

I do what is best. Perfection isn't achieved by not delivering a working
product. In my PPC app that task driven approach was absolutely necessary,
in fact the customer insisted upon it. In another app I have an application
API and no tasks at all. In an app I am writing now I am using ECO IV and
putting some "app logic" into the forms. As Cartman would say "I do what I
want".



That's because they obviously tried to write a framework that did
everything they could possibly want, well before they actually knew what
they wanted.

Exactly! It's one of the biggest pitfalls of any framework design, IMO.

It's the biggest pitfall of anyone who doesn't know what they are doing, no
matter what they are writing. My friend once wanted to learn VB after
working in quick basic for years. He decided to write an app for a video
shop, our friend was a manager and agreed to use it when complete. Every
week I'd visit him and he would be working on it. Months later he was still
working on it. He would tell me about how he had this great idea to mail
people who normally have Steven King films and let them know he had a new
film release next week, etc. Every week he was adding something new to the
DB structure (access). I was quite surprised to find out after months he
hadn't yet started on the interface.

"So Den, " I asked, "can you actually rent out videos with it?"
"No, " he replied, "not yet".

You see, this is nothing to do with framework design. It's simply an
example of someone who doesn't know what he is doing writing something he
believes is going to be the best X anyone has ever seen, and having no
chance of ever creating anything worth using. So, you are correct, but
maybe only because the frameworks you have seen were written by people who
either didn't know what they were doing or wanted to do something completely
different to your requirements.



The difficult part was hooking to changes that were occuring during
dragging. And I needed that in order to update my BOs in real-time.
I could have done it by polling for status, the way TActions work, but
then that wouldn't really be much of an improvement over the
conventional design. :)

Sounds really complicated to me. I'm sure you could have implemented
something much easier.


I'm not sure how this helps when one layer really *needs* to know
something about the other's implementation in order to feed it proper
data.

When I write layer 1 I ensure it knows nothing about layer 2. In fact layer
1 will work fine without layer 2. Layer 1 should do a specific job, no
matter what the context is that the user wants to perform that job within.


You can argue that you can always write additional layers until
you smoothen everything out, but the truth is that sometimes that would
simply require too much work to be worth it.

Or you could write the original layers properly :-)



A good example would be what I'm presently busy doing...
I'm writing an application that merges .NET and Win32 worlds by allowing
the plugins to be managed or unmanaged. All plugins implement the same
set of interfaces, and yet the host application needs to know which are
which, because the .NET ones need a lot of special attention to make
them play along.

Well, without knowing every detail of your app I cannot really comment.
Except to say that I'd probably have the plugins expose interfaces. I'd
probably also have a Win32 wrapper for the .NET ones which manages the
"special attention" and have my app just treat them all the same. Basically
I'd probably just write Win32 plugins, where some of those plugins load .NET
dlls and interop with them.


As I've (hopefully) explained above, it's the indirect references. When
an object from one layer needs to cater for a quirk in an object from
another layer (usually UI).

and hopefully I have convinced you that there needs to be no leak (although
I cannot really tell without 100% details, and I don't have time for that).
The Win32 plugin can know anything about the .NET code, but the app only
needs interfaces which provide it with a service without knowing how that
service is implemented.


As for other things you've said, I have to say I mostly agree. But I'll
continue to avoid OO frameworks as much as possible, until I meet one
that was built from the ground up with OO design in mind.

That's probably your problem :-) I doubt anyone else is likely to design
something you are happy with. You either have to write your own, help to
specify one, or learn to write code differently :-)


I have a feeling I'm in for a long wait, though. In the end, it's the
3rd-party controls that make or break any framework. And there's little
evidence that the ways of building UI controls are going to change any
time soon - not on the native ground and not in .NET.

I used ECO IV with DevExpress XtraGrid just this morning. I didn't struggle
at all.


Pete


.

Relevant Pages

  • Re: OODesign - OPF, design pattern
    ... I developed a Pocket PC app last year using the compact framework. ... Maybe my design is just very simple then, ... and its in the application layer not the business ...
    (borland.public.delphi.non-technical)
  • Re: Class with property named "Type"
    ... It has to be Type because this is all a part of a larger framework and ... the dll is actually a plugin I wrote for an application. ... customized version of the big app. ... So I am trying to make the plugins ...
    (microsoft.public.vb.general.discussion)
  • Re: which is a better dev language
    ... Java is not real time either - no runtime with a GC is. ... Managed code on the desktop succeeds for the same ... Run a .NET app on a Palm device with a Palm OS? ... Managed code has a slow startup as the framework is loaded and JITted ...
    (microsoft.public.pocketpc.developer)
  • Re: Which do I use for web design?
    ... your own "framework" may simply be a re-useable controller ... servlet, an event handler base class, some of the core event handlers, and ... Views, that other bit is replacing your Controller, and that other stuff is ... in an hour or so you can have a working app that set up entity classes ...
    (comp.lang.java.programmer)
  • Re: Whose Fish?
    ... "Reuse" has seemed to fall out of favor as a top claim of OOP. ... Language Framework: the framework of preexisting *reusable* classes ... When I start an app I first check to see if the tools I need to solve ... random number generator. ...
    (comp.object)