Re: dip Notions 2 Major Errors

From: Kurt (kurbylogic_at_hotmail.com)
Date: 09/12/04 

Date: 11 Sep 2004 23:21:55 -0700

> > Proper layered system design has clients either:
> > a) in the SAME Layer
> > b) in a HIGHER Layer

This is a totally incorrect assumption and seemingly the root of all
your arguments. The MOST SUCCESSFUL systems place clients in the
MIDDLE not at a higher levels.

Concider the .NET Framework. When you run an application in .NET
"static void Main()" is *NOT* the first executed line of code. The
Runtime has much to do before Main is even called, it reads
configuration files, evaluates code access security policies, creates
the AppDomain, configures remotable objects, dozens of things are done
before Main is ever invoked, heck Main probably still needs to be
converted from MSIL to machine code. To the Runtime the client is
your application and your application implements an agreed interface,
(not necessarily a strongly typed, but a well known agreed entry
point), namely static void Main() (or perhaps in ASP.NET it is
strongly typed, implements WebPage or IHttpModule, etc...). The point
is the Client is not always on top of its framework and in the best
ones it is in the MIDDLE.

Going back to your earlier points:

> 1) Falsely claiming that use of abstract interfaces
> can utterly eliminate client dependence upon a server
> 2) Improperly generalizing the fact that because
> concrete implementation classes depend upon
> THEIR abstract interfaces to errantly state:
> what dip causes and what we want is for system details
> to depend upon higher level policy

The .NET RUNTIME not the client/application that is dependent on the
concreate implementations of services. The RUNTIME has defined many
*interfaces* and methods for you to customize the services, such as
writing an additional remoting channel, you implement their interface,
you edit configuration files (in the format they defined) that the
RUNTIME will read and the RUNTIME will create an instance for your
application to use, the runtime can choose to ignore your settings and
use the machine.config, or other higher-level policies defined
elsewhere or perhaps yet to be defined in future release. Some
application might think it is writing a file in the Program Files
directory but (upcomming) Longhorn will create a private little world
for this ignorant program so think it replaced iexplorer.exe with a
virus when it did absolutely nothing at all.

> 1) With Strategy and Bridge [which are the mainstream non
> "Uncle Bob" sycophant terms for using abstract interfaces to concrete
> classes to reduce dependency] while higher levels minimize static
> dependency - compilation and linking - on lower levels STILL certain
> changes to lower level classes like:
> ~ changing their signature
> ~ changing their interface method order
> ~ changing data member types
> all MANDATE higher levels eve depending upon abstract interfaces to
> recompile and relink.

Lets say in the next release Microsoft changes a method signature...
so your code will not run? not necessarily, the newer runtime will
load an OLD version of the runtime you used to write your application,
because the RUNTIME sits on top of your application not below it it
can analyze your application determine its needs and create the
appropriate objects that support the interfaces you expect.

When was the last time Microsoft needed to recompile the .NET
framework/Windows or Sun/Java to run your application? If your code
fails to start because you didn't implement static void Main(), or if
your remotable object isn't created on the server because you didn't
add (or incorrectly) the entries to the configuration file, don't
expect them to change the framework to look for "static void
MyClientWantsToBeGod()". It wont happen. If your code doesn't run
on Windows because it was designed for Unix, they will tell you to use
an Adapter (aka virtual machine).

In summary, Don't let them use you; use them! If you want to apply
DIP to a web browser provide them with a set of interfaces perhaps
IOleControl, IViewObject, IDispatch, I*... okay ActiveX cotrols
requires more intefaces then I care to list but... there point is
there you use them, they use what you let them (so you can change it
later if you want).

- Kurt

Universe <> wrote in message news:<g4jvj09iji7phasusv4f53fafc225j2mlu@4ax.com>...
> Universe <> wrote:
>
> > "Ilja Preuß" <preuss@disy.net> wrote:
> >
> > > Universe wrote:
> > >
> > > > 2) Again proper hierarchical, layered system design is where higher
> > > > layers DEPEND upon lower layers for services.
>
> > > None of my programs depends on the XML parsing implementation layer, but
> > > only on the abstraction layer. I'd think that it's quite proper design.
> >
> > What the heck is an abstract interface in your abstract package but an
> > interface where a client uses the services of often multiple concrete
> > implementations. Thus the client DEPENDS, albeit as we want in a
> > REDUCED way, upon services.
> >
> > Proper layered system design has clients either:
> > a) in the SAME Layer
> > b) in a HIGHER Layer
> >
> > Elliott
>
> 1st and *mainly* think of system from a LOGICAL services and service
> user - client - perspective. PHYSICAL dependency issues/design should
> devolve from and be *led* by the overall LOGICAL system design.
>
> RCM's hallmark is conflation. confabulation of the LOGICAL and the
> PHYSICAL, and the improper placing of PHYSICAL matters over and above
> LOGICAL matters. It's *endemic* to the hardcore hacker view of
> things.
>
> Elliott
> --
> LOGICAL leads, PHYSICAL implements

Relevant Pages

  • Re: What doesnt lend itself to OO?
    ... >>server is a pure data transfer interface. ... essentially exposing the client or service implementation. ... >>paradigms can be abstracted just like any other problem space in an OO ...
    (comp.object)
  • Re: Text terminal rendering design
    ... free to give it any object that satisfies that interface. ... giving it a real facade object if I choose. ... Facade to avoid touching the client. ... completely incompatible with this subsystem interface. ...
    (comp.object)
  • Re: Abstract public member variales?
    ... Entity has no encapsulation and no real methods, but the great thing about it is that its public interface will never have to change during maintenance. ... Assuming there is at most only one Property instance for each property type, then the R1 collection class would own the smarts for finding the right one. ... However, I would point out that the client of the getter is someone who needs to collaborate with a specific Property, not the Entity itself. ... The second line generates a message to the Property for the collaboration. ...
    (comp.object)
  • Re: Text terminal rendering design
    ... Which is exactly what would happen in your case when the interface of the implementation object changes. ... But then you need a new object to own the actual responsibility within the subsystem implementation. ... I can pop in a facade in a completely painless manner without being forced to rename or kludge anything. ... Facade to avoid touching the client. ...
    (comp.object)
  • Re: Message-based vs. method-based interaction [was: Re: LSP and subtype]
    ... interface is always the method signature. ... We can name it for the owner context of what it does or we can name it for the client context, but we can't do both. ... overlaying some sort of developer structure on the 3GL syntax. ... Such separation is impossible to do with pure 3GL language syntax. ...
    (comp.object)
Loading