Re: A question about weak contract
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Sat, 24 Sep 2005 18:09:50 GMT
Responding to Johansson...
I'm reading a paper from a university and it says.
System boundary classes need weak contracts. - The user might not be trustable. * End-users do not accept that they have to test before a function call, which calls for weak contract.
Now to my question why do we have to use weak contract here as was said. Why is it not possible to use strong contract in that situation? Can somebody explain that.
Phlip provided an interesting perspective on this. But that addresses what you need to do in your system _given the nature of the contract_. The spin I would put on that is related to implied requirements and why one might want weak contracts on the boundary.
For a strong contract, at the most one only needs assertions that generate an exception on failure. IOW, the strong contract's preconditions are /expected/ to be honored by the client and the software is built with that assumption. So one does not expect the DbC assertions to ever fail. More important, the software does not provide any processing to deal with the failures based on explicit or implied requirements (e.g., "when the user provides incorrect input the system shall display a dialog with...").
OTOH, when the client cannot be trusted to honor preconditions, one should not bother specifying strong contracts. This is the typical case with human input through a UI. Essentially one has an implied problem space context that says that the user will screw up. Then the requirements will either explicitly or implicitly define what the system should do when that happens. [For example, requirements in the UI case are either explicit in the UI specification or are implicit in some general user friendliness goal.] IOW, the failure is expected and defensive measures need to be explicitly built into the software to deal with such failures _as part of normal processing_.
My concern in the author's statement is the implication that boundary contracts should /always/ be weak. IMO, that is a pure problem space decision. If I am providing a programmatic interface I would invariably opt for strong contracts for anything that needs to be enforced because it is the job of whoever is writing the client software to ensure that they honor the contract preconditions. That is, the client needs to be built properly. IOW, there is no difference in internal and external contracts that are fully implemented in software; it is just basic good practice to use contracts that are as strong as feasible.
[For tose who would argue that the <software> client might not be expected to understand some detailed service constraints I would argue that loose contracts is not the way to solve the problem. When bad data is supplied, what does the service do? Send a message back asking for better data? In practice all one can do is generate an excpetion that the client won't know how to process, which is usually not a very useful solution.
A much better solution from a service reuse perspective is to have the service specify a strong contract and deal with the semantic mismatch in a Facade that can trap the exception and provide a recovery or more graceful exit that is tailored to the client context. That at least isolates the "glue" code to a place where usage context is understood.]
************* There is nothing wrong with me that could not be cured by a capful of Drano.
H. S. Lahman hsl@xxxxxxxxxxxxxxxxx Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
.
- References:
- A question about weak contract
- From: Tony Johansson
- A question about weak contract
- Prev by Date: Re: Can you violate invariant within an operation
- Next by Date: RPG game in UML
- Previous by thread: Re: A question about weak contract
- Next by thread: RPG game in UML
- Index(es):
Relevant Pages
|
