From 6f591d79bcb99a86aa25ccd5b6acfa48a09802cc Mon Sep 17 00:00:00 2001 From: halw Date: Thu, 28 Jan 2010 16:17:07 +0000 Subject: [PATCH] Fixed OOSC2 link. 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 --- .../eiffelstudio/eiffelstudio-guided-tour/viewing-classes.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/viewing-classes.wiki b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/viewing-classes.wiki index 6abbb1bb..134ed38c 100644 --- a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/viewing-classes.wiki +++ b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/viewing-classes.wiki @@ -66,7 +66,7 @@ Next come two essential documentation views: Contract and 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 -- do or once 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 [http://eiffel.com/doc/oosc/ Object-Oriented Software Construction] , 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 Contract view, the next one, Flat Contract, 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 Flat Contract view provides the complete interface information for the class. Try it now on class LIST.