Re: OODesign - OPF, design pattern

Peter Morris wrote:
If the film is crap the book must be too :-)

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.

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? Say that the concept is ok, and accept it? Or
say that the concept is ok, and then force them to rewrite it? In any
way, I'm in trouble and so is my project.

when I hear someone tell me they're going to use the Visitor pattern to
extend their class, I always cringe a little.

I can understand why people would use it. For example, why should class that has absolutely nothing to do with XML know how to serialise/deserialise itself to XML, Binary, or a maybe a DB?

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);
?

Isn't it just an unnecessary back-and-forth action?

For the record, I'm not saying that's necessarily you, Peter (although
your initial post made me wonder quite a bit :))! I'm merely observing
my immediate reality.

My ProcessParameters stuff? The purpose of that is to allow the exact same code to run on PPC, Desktop, WebService, or WebSite.

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.

It's a bad example, but I've seen a case of abstracting away the
creation of the main form in a Delphi application a few years back. It
took around a 100 lines of code to do it and was IMO a shining
demonstration of what not to do

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

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

<snip>
My generator only "spews out" what I would have typed, but it does
it quicker and more accurately.

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

In reality, I don't see much difference in modifying a class diagram
and modifying a class manually.

It depends on what you do. For example, try manually writing a complex state machine. Give me UML any day!

As a matter of fact, I've just finished writing something along these
lines for a private project. It required some creative thinking, but I
think I've managed to keep the code down to the bare minimum.
I don't have that much experience with UML, so I might have really
wasted some valuable time by doing it manually. It's certainly
on my to-do list to research a better way of doing it the next time
I'll need it. Probably still won't be UML, though. :)

I've seen plenty of this. Having
OO framework that's capable of adapting to the wildest imaginable range
of changes in theory, and in the end still having to change just as much
code (but usually more, because every real-life framework is leaking
abstractions to outer layers, which in turn also need to be adjusted).

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.
And all the while you're overdoing it, the invisible walls just keep
coming closer together until you find yourself locked in something
that's not capable of addressing actual requirements anymore.

My problems weren't limited to a databinding level. They were
everywhere, e.g. in handling drag-n'-drop, responding to focus
changes... You know, all the little things that all 3rd-party controls
like to handle internally.

I don't see how dragging OPF stuff is any harder than the dragging you would normally write manually.

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

I wasn't talking about memory leaks. By "leaking abstractions" I meant
this: http://www.joelonsoftware.com/articles/LeakyAbstractions.html

This is easy to avoid. You just make sure your layers are in physically separate projects and make sure each does not
A: Reference a project it shouldn't
B: Include source from another project as its own

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

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. The underlying technology is a bit different on each
platform, so I need to maintain some amount of extra state to properly
handle the differences. I sometimes need to purposely leak an
implementation detail in order to save me from reinventing an otherwise
complex mechanism. It's a trade-off I'm willing to accept as long as it
doesn't become central to the development.

I'm guessing you're probably thinking I have double standards now. :)

The truth is, I'm comfortable with this degree of leaking abstractions
because they are occurring on a very high level, between two vastly
different worlds - .NET and Win32.

What I'm not comfortable with are the same leaks on the lower levels,
inside a single project, which is supposed to be completely under my
control. And from experience in Delphi.Win32 world, ISTM that these are
particularly hard to buff out, due to the way VCL and RTL are built.

I've not experienced this. Maybe it is because my layers do not reference each other in code.

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

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.

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.

My problem is, I've seen no convincing real-world examples

That's because I am not allowed to give you my source :-)

:)

--
Regards,
Aleksander Oven
.

Relevant Pages

  • Re: a pre-beginners question: what is the pros and cons of .net, compared to ++
    ... > party controls is expensive... ... This is where you end up fighting with the framework; ... LSA in the context of "Local Security Policy"? ... Let's say you want to add a new Anti-Virus service account to all ...
    (microsoft.public.dotnet.general)
  • 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)
  • What can we call such a framework
    ... These modules contain only a plain Form, all the required functions - they exist as methods and one resource file which contains an XML file in which the Layout of controls on that form as well as field names whose data should be loaded in a particular control, type of control, fields whose values have to be used for lookup, etc. are stored/defined. ... Once these ActiveX DLLs are compiled and registered they are automatically available in various menus and in the core EXE and when the user clicks on a particular menu the form stored in the DLL becomes Visible populated with all the controls in the exact location that they have defined in the XML file which is actually compiled in the ActiveX DLL itself, ... The company which is using this framework developing business automation software. ...
    (borland.public.delphi.non-technical)
  • Re: a pre-beginners question: what is the pros and cons of .net, compared to ++
    ... Framework is filling in a very large number of the useful calls that were ... Web controls will run on newer ... XML and various CGI/ISAPI interfaces. ... > certainly don't need .NET to run web services. ...
    (microsoft.public.dotnet.general)
  • Re: Server Control Deployment and Client Scripts?
    ... files in the aspnet_client folder via your deployment. ... control on a different version of the Framework and you want to ensure that ... adding new versions of the client files is fine. ... >book ASP.NET server controls and components. ...
    (microsoft.public.dotnet.framework.aspnet.buildingcontrols)
Loading