Remove a redundancy introduced in last change.

Author:vwheeler
Date:2014-04-28T23:38:53.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1333 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
vwheeler
2014-04-28 23:38:53 +00:00
parent fc457d96c4
commit 0f80dd87e9

View File

@@ -79,7 +79,7 @@ Boolean properties have a different convention. Instead of one set-routine, it h
==Implementation==
For flexibility, EiffelVision 2 is built using the bridge pattern. This means that every platform-dependent component of the library consist of two classes, plus an implementation class for each platform (currently two). One is the <eiffel>interface</eiffel>. All the features of interfaces do nothing except delegate the call to the implementation object which is coupled to it. This object has the static type of the implementation-interface with the name of the interface class, with an "<eiffel>_I</eiffel>" suffix. The implementation classes (with an "<eiffel>_IMP</eiffel>" suffix) then inherit from this implementation-interface class to implement platform-specific features. At run time, these platform-specific implementation objects (instantiated from these "<eiffel>_IMP</eiffel>" classes) are then polymorphically attached to the to the "<eiffel>_I</eiffel>"-type attributes (typically named "implementation") to provide the platform-specific services.
For flexibility, EiffelVision 2 is built using the bridge pattern. This means that every platform-dependent component of the library consist of two classes, plus an implementation class for each platform (currently two). One is the <eiffel>interface</eiffel>. All the features of interfaces do nothing except delegate the call to the implementation object which is coupled to it. This object has the static type of the implementation-interface with the name of the interface class, with an "<eiffel>_I</eiffel>" suffix. The implementation classes (with an "<eiffel>_IMP</eiffel>" suffix) then inherit from this implementation-interface class to implement platform-specific features. At run time, these platform-specific implementation objects (instantiated from the "<eiffel>_IMP</eiffel>" classes) are then polymorphically attached to the to the "<eiffel>_I</eiffel>"-typed attributes (typically named "implementation") to provide the platform-specific services.