Re: What doesn't lend itself to OO?

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


Date: 22 Jul 2004 03:14:39 -0700


> I would like a notion of what others here consider to be /kinds of/ projects
> to which OO is not the greatest idea and that Procedural Programming is a
> much better one (ignore for now the other paradigms).
>
> When trying to discuss the merits of OO with a friend of mine, I'd like to
> be better armed with project ideas where OO is best avoided.
>
> My knee jerk reaction to
>
> What is OO not great at?
>
> is naively
>
> Nuthin.
>
> But I realize that there are there are some things such as OO to RDB mapping
> that can be very difficult..
>
> I'd like some help understanding what others have bumped into that don't fit
> into the OO mold.

At the core of OO is close association of state and operations on that
state.

This close coupling can cause problems in the real world (at the OOD,
OOP level) for example, middleware architectures over the last twenty
years have tended to be object based and statefull, so system A
creates on object X1 on system B, an object and it's state is then
held on system B, if A doesn't do anything for the next two months,
that object still needs to be maintained. This obviously scales badly,
if hundreds of client systems create remote objects, then hundreds of
objects need to be explicitly maintained....thus the rise of stateless
service oriented architectures (i.e. really just exposing an old
fashioned functional API). In the world of the internet, potentially
we have millions of remote clients, so rather than expose an object
interface and potentially have to manage millions of objects, we
expose a functional one (stateless object) and leave the maintanance
of state largely the responsibility of the client.

The other problem with a statefull object model in this regard is if
you want to create a farm of servers and a load balancer, if the
object only exists on 1 out of n servers the load balancer needs to
know which server that is when the client submits a method call,
that's a real pain, it's much easier to make the interface stateless
and then the load balancer can pick any available server to service
the request.

Similarly in multi threaded environments volatile state in an object
can be a headache when sharing objects between multiple threads, we
need to either ensure that updates to internal state are consistent
and thus usually single threaded (or even better the application is
single threaded), make sure that the state cannot change or try not to
share volatile data between threads. The more I do this, the more my
object models migrates towards a factory/fixed state world that could
be argued is similar to the world of currying functions (though this
is probably at best a naive view as I'm no expert on currying
functions).

Now it can and has be argued that OO is a superset of the procedural
world BUT I think that may be a bit of a cop out (sorry), to design a
stateless service layer, you really are taking a conscious decision to
externalise the state of an OOA entity in order to give you
scalability and to allow things like load balancing - yes it's
expressed in OO terms, because those are the main stream tools we have
at hand but I don't believe it is mainstream OO because it breaks a
central tenet of OOD i.e. an object is the encapsulation of behaviour
and state - it would be like claiming a sausage is a burger, but just
a different shaped one, made out of pork, and there is nothing in the
world of burgers that says

a) what shape it is.
b) what it's made out of.

QED, sausage IS A burger.

As ever, Horses for courses.