Re: implementing roles in OOP......

From: Mark Nicholls (Nicholls.Mark_at_mtvne.com)
Date: 04/27/04 

Date: 27 Apr 2004 03:32:03 -0700

> As far as your real problem is concerned... I don't have a clue. B-)
> More precisely, I don't see a cookbook suite of techniques that can be
> universally applied. The problem I have is that almost everything is
> supplied by the user.
>
> For example, consider the pipes & filters pattern example:
>
> <message> -------> [Decrypt] -------> [Authenticate] ---------> ...
>
> The user has to supply the functionality for decryption and
> authentication. The user also provides the message definition. OK,
> Visitor is an infrastructure to touch the message with arbitrary
> functionalities. But what infrastructure can you put in the library?

There are a good set of off the shelf components that you can provide
e.g.

WormholeNodes in and out

e-mail
external quese
files
http puts and gets
etc
etc

Standard processes hmmmmm these are more troublesome, but in my
context within an organisation you can (should) define a set of
standard data structures that standardise the main data that is passed
between systems so

Standard message formats at the enterprise level can be put in a
standard library.

Now in the same context there are probably 5/6 central systems (I'm in
a large organisation but I can safely guess that 80% of the traffic
goes through 20% of the systems and that's about 5-10 systems).

So now I should be able to define a standard set (probably as
objects/application/instances sitting at the end of queues) of
adapters.

Given that I should now (theoretically) be able to plumb my business
applications together into a smooth seamless flexible macro system
.........

And of course I could do with a standard set of interfaces that 3rd
party components need to conform to because I have a standard engine
(or engines) which can be used to pass messages up and down a network
of these nodes.

[The book is a very good book and paints a complete set of
complimentary patterns which are half a step away from a concrete
framework]

Well that's the theory anyway.

I can go and buy such things off the shelf e.g. MS Biztalk, Tibco
etc....but these I think are quite centralised systems and really
another step along from where I am now. The 1st step to me is to
provide something similar to these packages that can be used in a more
pragmatic way to plumb systems together - after a while the main
software development activity should be simply writing adapters to
systems and creating and deploying networks of components in
standalone applications.

>
> I don't see much. The body of each operation must be supplied by the
> user because it will depend carnally on the message. The message itself
> is also formally defined by the user. So all I see that goes in the
> library is the implementation of the callback. However, that's more of
> an aspect (i.e., something to be inserted into the user's existing code)
> than a library class.

Yep I can see that.

>
> IOW, I see that more in terms of templates for code fragment generation
> that one applies to existing user code. I could easily envision an
> implementation of your infrastructure where (once the user identified
> the pattern, messages, and filters) a perl script would be invoked to
> look up a template in the library and insert it into the user's input
> class. Another perl script could be called to insert the code to daisy
> chain the filter functions as a series of pipes. [A perl script
> wouldn't be a good choice but this is just an example of the
> plausibility of the template-based code generation view.]

OK you're looking at it from a code generation perspective - which is
fine - I was looking at it from a set of concrete classes, an engine
or two and an abstract base class from which user defined 'processes'
would inherit (I prersonally wouldn't implement it as an ABS but you
know what I'm saying).

>
> Carrying this a bit further, one could provide an IDE as a set of
> wizards for the patterns. Those wizards would prompt the user for the
> location of the code for each role within the patterns and then they
> would modify that code with the "glue" code. But this is in the world
> of application building and code generation rather than libraries and
> "canned" infrastructures.

The conversation about glue and COM wasn't directly connected with
this - it was more of an observation from a general design paralysis.

I can see where you're going.

My current glue is an engine that processes a abstract data structure.

>
> FWIW, I see exactly this sort of automation being the future of software
> development. The developer writes the individual functionalities
> according to some rules for good encapsulation, etc. at the component,
> subsystem, or task level and then jumps into an IDE that provides the
> glue code for linking them together.
>
> In the translation world there is a very similar notion and some
> research has been done on "implicit bridges". In translation subsystems
> communicate through highly disciplined, two-way interfaces known as
> bridges. Today these are specified by the developer in abstract action
> language. The notion of an implicit bridge is one where the bridge is
> defined and implemented automatically once one provides a <roughly>
> object-to-object mapping between the subsystems.

I haven't got a clue how commercial versions of this sort of thing
work, they may well work in this translationist way.

>
> This sort of thing has already been implemented in the specialized case
> of UI/DB pipeline applications using layered models with "canned" and
> hidden infrastructures. That's because the mapping is easy since it's
> close to 1:1. In the general case, though, the mapping is not 1:1.
> However, the basic idea is the same: once the mapping is understood, the
> interface can be generated automatically.
>
> ------
>
> Now that we've identified the disconnect, I don't plan to respond to
> your currently open responses unless there's something in the OOA/D
> application building context you want to pursue. If so, let me know.
>

hmmmmm

Actually the mists have cleared to a degree, the iceberg is fading
from view and the klaxon is no longer sounding.

Your comments about modeling relationships have been very useful, as
was the OOA/D process critisisms i.e. the jump to number 5.

[I actually can now see how to compose and reuse the sort of
implementation 'patterns' I'm after - this may well give you a shiver
as I understand you disaproved of this sort of approach]

I may embark on v3 of my prototype as v2 was as unsatisfactory as v1 -
though it did work.

> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> hsl@pathfindermda.com
> Pathfinder Solutions -- Put MDA to Work
> http://www.pathfindermda.com
> (888)-OOA-PATH

Relevant Pages

  • Re: Curses for win32 with VT100/ANSI support
    ... There is a case for including it in the standard library, ... Compiler writers write compilers not libraries. ... Not really there are far to many types of network to do a standard ... some sort of communication but not always a network. ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... If you are claiming there is a reason to avoid the mechanisms the standard provides to allow portability then it is up to *you* to prove your point, not up to others to disprove it. ... but you can hardly blame the consequences on the Standard headers. ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... want to have standard headers included in their own headers which ...
    (comp.lang.c)
  • Re: Any Clojure users here?
    ... ABCL and I've been contributing to it for a while (though since some ... from the CL standard or from the Java API, ... You can use CFFI-based libraries in ABCL without ... Yes, but without a Clojure standard, it's hard to know what the "core" ...
    (comp.lang.lisp)
  • Re: comparing doubles for equality
    ... AFAIK there is no ANSI/ISO standard for it. ... Fortran 95 seem to have some built-in operators but it's not clear ... LIA,GIA,ICE libraries for interval methods in C++ from Delisoft ... Actually I've been for quite some months proposing getting together ...
    (comp.programming)