|
| Authored by: Anonymous on Monday, April 23 2012 @ 09:09 PM EDT |
I don't see any point in pushing the programmers
concept of "contract".
It can only confuse the layman. In fact, from the
laymans point of view,
we should tell them to forget that word, because it is
nothing like the
contract that they know. There is no negotiation, and
no meeting of the
mind.
Sent from my smart phone.
Gringo
[ Reply to This | Parent | # ]
|
|
|
| Authored by: Anonymous on Monday, April 23 2012 @ 09:52 PM EDT |
A contract in software design is very similar to a legal contract. Let me try to
translate (see Bertrand Meyer for a fuller explanation including correctness
impacts and lots of technical jargon...):
The API is the agreed terms of the contract - i.e. the facts that establish the
"meeting of the minds";
The specification is like the offer - i.e. the supplier of the service (the
library) offers to provide the service on a defined set of terms (the
constraints - preconditions, postconditions and invariants);
Inclusion of the package into a programme is "acceptance" of the terms
offered by the supplier (library);
Benefit for the caller -- the service, consideration for the supplier -- you
adhere to the constraints and I have a clear scope to implement.
For a judge and lawyers, I think this might help the penny drop.
When you want someone to understand your position, you don't just waffle on
about your view in your language, you need to put your argument into terms that
they understand and which relate to their experience and background.
I think we might do well to stop trying to drag the legal profession into our
mind space and present our case in a form that resonates in theirs...
Just my 2p...
[ Reply to This | Parent | # ]
|
|
|
| Authored by: Anonymous on Tuesday, April 24 2012 @ 11:36 AM EDT |
I think the correct idiom is "programming by contract"
The programmer is just programming what written in the contract.
Accepted input and resulting output is exactly defined.
All other will give a exception
and there are no side effects.
The point is: The programmer implementing the contract doesn't know anything (or
should forget al)l how this code will be used later in other programs.
/Arthur [ Reply to This | Parent | # ]
|
|
|
| Authored by: Anonymous on Tuesday, April 24 2012 @ 03:19 PM EDT |
Y'all seem to be comparing the software component to a physical item, such as a
brick. This is true as far as it goes, in that both have defined characteristics
and usage restrictions, but software can also be expected to change over time.
Thus a software library and its routines also include an implied social
contract that the rules for using the library components will not be
arbitrarily changed during updates and bug-fixes. As I recall, Novel
l v. Microsoft is about such a changing of API components for improper
reasons.
I offer the phrase "civilized behavior" as evidence the lay public
both expects and understands such implied social contracts. --DonW[ Reply to This | Parent | # ]
|
|
