Re: What doesn't lend itself to OO?

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

Date: 23 Jul 2004 02:23:24 -0700

> > The problem with stateless programming is that it turns object
> > orientated programs into effectively procedural programs. Since the
> > majority of people agree with the power of the OO paradigm I don't
> > think this is a direction that we should be heading technologically.
>
> Not necessarily. As an extreme example, in translation it is routine to
> create the OOA model with stateful objects. The transformation engine
> can then separate state and behavior into different objects. (In a
> JB/J2EE environment a single OOA class can often become four classes at
> the 3GL level.) In fact, in a translation environment it is fairly
> routine to target C and sometimes Assembly rather than an OOPL for
> performance reasons. So the design can be quite OO while the 2/3GL
> implementation is something else again. However, in a translation
> environment one doesn't have to maintain the 2/3GL code, so the issue
> becomes academic. B-)
>
> I would point out, though, that clients and servers are different
> critters. The most efficient and robust interface between clients and
> server is a pure data transfer interface. So the client should be
> completely indifferent to whether the server is constructed with
> stateless objects or not and vice versa -- the interface will look the
> same either way so the respective implementations are completely decoupled.
>

I think I agree with this, if I understand it, but I think that a
"pure data transfer interface" is not a particularly natural OO beast
- I have no problem using it, and have no problem with it being un OO
(it seems an aestetic point).

"the interface will look the
 same either way so the respective implementations are completely
decoupled"

I'm not so sure about this, or I don't completely understand.

i.e.

statefull approach

class CRemoteClock
{
    private Time time;

    CRemoteClock(Time time)
    {
       this.time = time;
    }
    
    void SetTime()
    {
    //set the time.
    }
}

Stateless approach

class CRemoteClockAPI
{
    static void SetTime(Time time)
    {
    //set the time.
    }
}

The interfaces look different to me - traditional COM/CORBA objects
look like CRemoteClock, stateless ones like web services etc look like
CRemoteClockAPI.

> I would also point out that servers have unique problem spaces where
> different paradigms -- including statelessness -- apply. Those
> paradigms can be abstracted just like any other problem space in an OO
> manner. That will naturally result in a bunch of dumb data holder
> objects like Request, Message, and Buffer that are ephemeral and a few
> control-rich objects like Dispatcher, Query, and XMLPaser with only
> scope variables.

I accept this, but its a bit like the burger/sausage thing, if I make
a long think pork burger is it a burger of a sausage, i.e. when does
an OO approach really become a procedural one?

If I did this for all my code (and I do it more than most e.g. my
likeing for dumb readonly shared composites and behaviour rich
visitors) you would suggest I wasn't doing OO I think.

>
> IOW, a server environment is a classic example of parametric
> polymorphism as applied in OO development. One encodes simple, generic,
> invariant behaviors while leaving the detailed differences to external
> data. That sort of parametric polymorphism is manifested in dumb data
> specification objects and dynamically instantiated relationships. On
> the client side it is used to reduce code size by putting details in
> external configuration data. In a server, the parametric data is
> supplied more dynamically by the client or the DB, but the idea is
> basically the same.

I'll have to think about that one.

>
> Where the problem arises is when "canned" infrastructures designed to
> hide the client/server boundary as an application layer define a layer
> interface that exposes the server implementation model. That forces the
> client application to employ the server implementation model. That is
> bad OO.
>
hmm, you'll have to illustrate.

>From my experience in the world of automation via serial control, i.e.
very message based, the communication is very stateful and does expose
some an abstracted hopefully standardised view of the server model,
and in fact I build a proxy that captures that model and then passes
serial messages off to the remote device.

In the world of stateless SOA the move is away from that, simply from
the perspective of client/server scalability and connection
management, it doesn't apply to automation as the connection is
usually 1:1.

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: What doesnt lend itself to OO?
    ... The whole idea that a subsystem is just ... > The first line exists in the server. ... objects between client and server i.e. as far as the client code is ... > external interface is the traditional input interface whose ...
    (comp.object)
  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • Re: What doesnt lend itself to OO?
    ... > A pure data transfer interface consists of messages that have a message ... > essentially exposing the client or service implementation. ... stateless ones like web services etc look like ... I was using the IT view of client/server where the server ...
    (comp.object)
  • Re: MSAccess to Web App
    ... I don't think you understand the meaning of "stateless" in this ... continuous awareness on the server of what the client is doing. ... again that is needed to establish the context of its next request. ...
    (comp.databases.ms-access)