Darren New schrieb:

>> 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.

Ah, I get that point now... my mental image had dependency the other way 
round for some obscure reason.

Now that's a problem indeed: Changing a contract is a particularly 
problematic change. Because that's why contracts are there in the first 
place.

Note that a good contract places as many constraints on /both/ parties 
as possible, to get some "room to breathe" in case either side needs to 
be modified.


>>> 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.

Maybe, but at any rate OO has been the most influential of these in the 
last decades.

>> 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.

As my point is the tremendous benefit thing, I can live with that 
assertion of yours.

Post a reply to this message