So, it’s really a contractual thing, not so much a logic
thing.
Exactly. The contract spells out the requirements that the client software
must adhere to and the results the server software will deliver.
Doesn’t that spread logic around anyway, though?
It does a bit. In Eiffel the pre and post conditions are syntactically part
of the method definition. And since pre/post conditions are inherited, you
only specify them at the parent level. You don’t have to keep repeating
them in throughout the inheritance heirarchy.
Here’s a twist on the original idea … you could put them in the same file:
Class Person
def greet(other_person)
blah
end
precondition(:greet) do |other_person|
other_person.hand_condition != clammy
end
postcondition(:greet) do |result|
other_person.spouse == self && self.spouse == other_person
end
end
Here, the precondition/postcondition class methods can dynamically build the
:pre/:post methods and call the blocks, but only if
precondition/postcondition checking is enabled.
Aside: The contract in the above example is not the same as the examples in
previous messages. I delibrately changed it so there was an explicit
precondition. I figured the exact contract wasn’t important to the course
of this discussion.
I’m wondering what happens when the actual method needs a
parameter to pass another test, does the programmer have to
go open another file and assert the test there? It still
feels like spreading logic around that really belongs in one
place.
The contract is the formal spec of what you say you will do. The code is
where you do it. So there is some inherit duplication of information.
···
–
– Jim Weirich / Compuware
– FWP Capture Services
– Phone: 859-386-8855