mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-07 23:32:42 +01:00
Code Issues Packages Projects Releases Wiki Activity

Fixed OOSC2 link.

Browse Source 
Author:halw
Date:2010-01-28T16:17:07.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@416 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2010-01-28 16:17:07 +00:00
parent f49ac43dc3
commit 6f591d79bc
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/current/eiffelstudio/eiffelstudio-guided-tour/viewing-classes.wiki
View File

@@ -66,7 +66,7 @@ Next come two essential documentation views: <code>Contract</code> and <code>Fla
The contract form (also known as the '''short form''' of a class) is the class text deprived of any internal detail to retain interface information only. It discards any feature that's not exported (available to all clients); for the retained features, it discards the implementation -- <code>do</code> or <code>once</code> clause -- but retains the header (feature name, arguments, results), the header comment, and the contracts (precondition, postcondition, invariant) minus any contract clause that refers to a non-exported feature and hence would be useless to clients.
As you will know, particularly if you have read the book <span> [http://eiffel.com/doc/oosc/ Object-Oriented Software Construction] </span>, the contract form is the preferred way of documenting software elements, especially reusable components, as it provides clients with just the right level of abstraction: precise enough thanks to the type signature and the contracts; clear enough thanks to the header comments; and general enough since it omits implementation details that are irrelevant to client programmers (and might lead them to write client code that won't work any more if the implementation changes).
As you will know, particularly if you have read the book [[Object-Oriented Software Construction, 2nd Edition]], the contract form is the preferred way of documenting software elements, especially reusable components, as it provides clients with just the right level of abstraction: precise enough thanks to the type signature and the contracts; clear enough thanks to the header comments; and general enough since it omits implementation details that are irrelevant to client programmers (and might lead them to write client code that won't work any more if the implementation changes).
In practice you will often want to use, instead of the <code>Contract</code> view, the next one, <code>Flat Contract</code>, also known as "flat-short form" and "interface form", which applies the same rules to the flat form rather than to the original class. This means it shows information on all the features of the class, immediate (defined in the class itself) as well as inherited, whereas the short form, non-flat, only considers immediate features. The <code>Flat Contract</code> view provides the complete interface information for the class. Try it now on class <code>LIST</code>.