clipka wrote:
> In contract-oriented programming, how could you possibly break the Order 
> class by a change in the Customer class? 

By changing the contract of the customer class that the order class relies 
on.  I haven't seen anything in a language where the order class could say 
what parts of the customer class's contract it relies upon.

> As far as that is concerned, such a violation /could/ be detected by 
> static code analysis (within limits regarding the complexity of the 
> pre-/postconditions), or by running the application in debug mode with 
> pre-/postcondition checks enabled (within limits regarding test coverage).

One would hope.

> I don't see where the C in ACID could be verified any differently.

It's more mathematical. Of course, it's harder to enforce everything in SQL 
that you can express in (say) Eiffel.

> In Java, if you'd be smart you wouldn't declare function arguments as of 
> a certain /class/ type, but of a certain /interface/ type. You can then 
> easily "upgrade" to a more powerful type without changing any existing 
> code (except for the actual container object creation).

Right.

> In other OO programming languages, you could do the same using the type 
> names of abstract base classes instead of whatever actual implementation 
> is used.

Right.

> If you did your homework properly, most OO languages will allow you to 
> pull off the stunt even without recompiling most of the code.

Probably. But ... so? :-)

> 
>> The point I was making is that there are lots of paradigms
> 
> I presume this sentence was left incomplete? (Otherwise: Erm... yes, 
> there are indeed lots of paradigms :-))

Sorry. There are lots of paradigms that let you do things like change the 
type of a variable without having to have OO.

> But my primary point was that the OO /paradigm/ was highly influential 
> in the creation of such type libraries - and that a non-OO approach 
> doesn't get you there, unless you somehow "emulate" OO behavior.

Ehn. I'll disagree. I'll agree that container classes and GUIs both 
benefited tremendously from an OO treatment, but I'll also assert that 
non-OO modules and libraries (say, Ada83's) did nicely without the need for OO.

> In the case of the STL, the library in a sense uses a "static OO" model: 
> The implementing classes are /designed/ to be interchangeable without 
> code change (to the extent that they implement the same "concept"); they 
> are /designed/ to use the same function names and parameters for the 
> common functionality. The only thing they lack is a language that allows 
> them to carry this flexibility over to run-time.

Well, yes. But that doesn't make them designed based on OO, any more than 
UNIX's file system design was based on OO just because everything was a file 
and used the same read and write calls.

>>> Note that data encapsulation /is/ an OO trait. 
>>
>> It's a trait of a lot of languages. It's not the definitive trait of OO.
> 
> This discussion seems familiar to me. I'd say it is /the/ most important 
> trait of OO.

Yes. But it's not definitive. You can't have OO without encapsulation, but 
there are many ways to have encapsulation without OO.  The container example 
you gave was all about encapsulation, not OO.

>> Does the STL's dequeue inherit from the STL's stack, or vice versa?
> No, but they both "inherit" from the same "concepts".

Um, ... No.  Have you ever worked with a modular language that *isn't* OO? 
Ada, Modula-3, something like that?

> And, as you say yourself, subclassing and inheritance is one of the 
> primary defining features of /class-based/ OO. Given that there is 
> non-class-based OO, obviously subclassing and inheritance /cannot/ be 
> the primary defining features of OO in general.

I don't think there is a primary *defining* feature of OO in general.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message