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