[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Is OO a deliberate fraud?



Folks,

Fred wrote:
> I'm not completely convinced that OO is good for this either -- makes for
> good reasoning about the system's structure, but I've had issues with this
> sort of thing and C++ in the past (Java suffers a bit less here).  Won't
> bore you with the detail here; for the curious, http://frmb.org/rapp.html

In creating the software for my last contract, I was somewhat constrained by
the need to write code that was maintainable by others not versed in CSP,
and so used a distinct split between process wrappers (using JCSP) and the
code within them (C# without JCSP), the goal being that understanding JCSP
was not required unless you were changing JCSP things.

I did, however, very much appreciate the use of proper OO stuff for what
.NET terms value types[1], where it is useful to associate the operations
possible on a type (or group of types using single inheritance and abstract
types) with the data. For example, I was manipulating the operations that a
machine can perform on a length of material, and for that situation setting
up a class hierarchy that did that resulted in a very nice, clean and easy
structure. Other aspects of the OO paradigm didn't work so well, and in a
more CSP-aware language[2] and without the requirements of maintainability,
I would have used a more process based approach.

In short, I think that process based systems do benefit from a degree of OO,
but (as I currently see it) only where you are defining a new data type and
the operations that are performed on it.

One other thing I have come to appreciate is the integration of collection
types into the CLR and languages. Although collections are generally
implemented as reference types there is a lot of compiler and language
support that makes the contents nearly invisible. In occam terms this would
be a bit like saying:

DATA TYPE Point
  INT x:
  INT y:
:

PROC draw.points([] Point plist)
  SEQ Point p IN plist
    DrawTo(p[x], p[y])
:

PROC draw.points.reversed([] Point plist)
  SEQ Point p IN plist.Reversed()
    DrawTo(p[x], p[y])
:

But in .NET you can define collections in several ways, including the use of
generics (polymorphism done well), have collections that have several
alternative orderings or with filters, and so on; much more powerful than
I've seen elsewhere.

Regards,

Ruth

[1] Value types in C# are just like classes but for the fact that values are
always copied, in the same way as integers or doubles. 

[2] I find JCSP hard going in terms of boilerplate and connecting things
together, and dearly miss the simplicity of occam's syntax and compiler
checks!