mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2026-04-04 17:19:23 +02:00
Author:halw
Date:2009-05-11T22:10:12.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@213 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
@@ -1,5 +1,4 @@
|
||||
[[Property:title|4 Classes]]
|
||||
[[Property:link_title|I2E: Classes]]
|
||||
[[Property:title|I2E: Classes]]
|
||||
[[Property:weight|-11]]
|
||||
[[Property:uuid|218bead9-428e-f61d-1e45-7eea4291d895]]
|
||||
A class, it was said above, is an implementation of an abstract data type. This means that it describes a set of run-time objects, characterized by the ''' features''' (operations) applicable to them, and by the formal properties of these features.
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
[[Property:title|12 Combining Genericity and Inheritance]]
|
||||
[[Property:link_title|I2E: Combining Genericity and Inheritance]]
|
||||
[[Property:title|I2E: Combining Genericity and Inheritance]]
|
||||
[[Property:weight|-3]]
|
||||
[[Property:uuid|912e4c38-9add-e478-59c3-5c10aa75d784]]
|
||||
Genericity and inheritance, the two fundamental mechanisms for generalizing classes, may be combined in two fruitful ways.
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
[[Property:title|13 Deferred Classes and Seamless Development]]
|
||||
[[Property:link_title|I2E: Deferred Classes and Seamless Development]]
|
||||
[[Property:title|I2E: Deferred Classes and Seamless Development]]
|
||||
[[Property:weight|-2]]
|
||||
[[Property:uuid|b3264238-f160-a6fc-0b03-adcd80b1f55a]]
|
||||
The inheritance mechanism includes one more major notion: deferred features and classes.
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
[[Property:title|6 Design by Contract and Assertions]]
|
||||
[[Property:link_title|I2E: Design by Contract and Assertions]]
|
||||
[[Property:title|I2E: Design by Contract and Assertions]]
|
||||
[[Property:weight|-9]]
|
||||
[[Property:uuid|f563aa75-3a5a-5110-b4f1-07da5448f668]]
|
||||
If classes are to deserve their definition as abstract data type implementations, they must be known not just by the available operations, but also by the formal properties of these operations, which did not yet appear in the preceding example.
|
||||
@@ -134,7 +133,7 @@ feature
|
||||
end -- ACCOUNT
|
||||
</code>
|
||||
|
||||
This is not actual Eiffel, only documentation of Eiffel classes, hence the use of slightly different syntax to avoid any confusion ( <code>interface class</code> rather than <code>class</code>). In accordance with the Uniform Access Principle (page [[4 Classes|7]] ), the output for <code>balance</code> would be the same if this feature were a function rather than an attribute.
|
||||
This is not actual Eiffel, only documentation of Eiffel classes, hence the use of slightly different syntax to avoid any confusion ( <code>interface class</code> rather than <code>class</code>). In accordance with the Uniform Access Principle (in [[I2E: Classes|Classes]]), the output for <code>balance</code> would be the same if this feature were a function rather than an attribute.
|
||||
|
||||
You will find in EiffelStudio automatic tools to produce the Contract Form of a class. You can also get the '''Flat Contract''' form, based on the same ideas but including inherited features along with those introduced in the class itself. EiffelStudio can produce these forms, and other documentation views of a class, in a variety of output formats including HTML, so that collaborative projects can automatically post the latest versions of their class interfaces on the Internet or an Intranet.
|
||||
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
[[Property:title|2 Design Principles]]
|
||||
[[Property:link_title|I2E: Design Principles]]
|
||||
[[Property:title|I2E: Design Principles]]
|
||||
[[Property:weight|-13]]
|
||||
[[Property:uuid|529659bd-ec13-5805-87f2-2fd9318ad442]]
|
||||
The aim of Eiffel is to help specify, design, implement and modify quality software. This goal of quality in software is a combination of many factors; the language design concentrated on the three factors which, in the current state of the industry, are in direct need of improvements: reusability, extendibility and reliability. Also important were other factors such as efficiency, openness and portability.
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
[[Property:title|8 Event-Driven Programming and Agents]]
|
||||
[[Property:link_title|I2E: Event-Driven Programming and Agents]]
|
||||
[[Property:title|I2E: Event-Driven Programming and Agents]]
|
||||
[[Property:weight|-7]]
|
||||
[[Property:uuid|16fdab60-ae42-1bb8-f4bb-89e34d18a842]]
|
||||
The division of roles in object technology is clear: of the two principal constituents of a system, object types and operations, the first dominates. Classes, representing object types, determines the structure of the software; every routine, representing an operations, belongs to a class.
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
[[Property:title|7 Exceptions]]
|
||||
[[Property:link_title|I2E: Exceptions]]
|
||||
[[Property:title|I2E: Exceptions]]
|
||||
[[Property:weight|-8]]
|
||||
[[Property:uuid|e3e10dac-0dd7-bbe1-240c-6a6985c7376a]]
|
||||
Whenever there is a contract, the risk exists that someone will break it. This is where exceptions come in.
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
[[Property:title|9 Genericity]]
|
||||
[[Property:link_title|I2E: Genericity]]
|
||||
[[Property:title|I2E: Genericity]]
|
||||
[[Property:weight|-6]]
|
||||
[[Property:uuid|091c0b65-73de-b454-b3f2-d8752983780e]]
|
||||
Building software components (classes) as implementations of abstract data types yields systems with a solid architecture but does not in itself ensure reusability and extendibility. Two key techniques address the problem: generosity (unconstrained or constrained) and inheritance. Let us look first at the unconstrained form.
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
[[Property:title|10 Inheritance]]
|
||||
[[Property:link_title|I2E: Inheritance]]
|
||||
[[Property:title|I2E: Inheritance]]
|
||||
[[Property:weight|-5]]
|
||||
[[Property:uuid|acf84989-0e7c-f2f7-427a-19e7fce404ce]]
|
||||
Inheritance, the other fundamental generalization mechanism, makes it possible to define a new class by combination and specialization of existing classes rather than from scratch.
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
[[Property:title|Invitation to Eiffel Copyright]]
|
||||
[[Property:link_title|I2E: Invitation to Eiffel Copyright]]
|
||||
[[Property:title|I2E: Invitation to Eiffel Copyright]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|ce7b4af4-b669-9fec-92e1-c24c4f089336]]
|
||||
Title: Invitation to Eiffel, Eiffel Software Technical Report TR-EI-67/IV.
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
[[Property:title|3 Object-Oriented Design]]
|
||||
[[Property:link_title|I2E: Object-Oriented Design]]
|
||||
[[Property:title|I2E: Object-Oriented Design]]
|
||||
[[Property:weight|-12]]
|
||||
[[Property:uuid|e0a1f24e-5dd7-e5f8-8be8-8da32cc6a91c]]
|
||||
To achieve reusability, extendibility and reliability, the principles of object-oriented design provide the best known technical answer.
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
[[Property:title|11 Polymorphism and Dynamic Binding]]
|
||||
[[Property:link_title|I2E: Polymorphism and Dynamic Binding]]
|
||||
[[Property:title|I2E: Polymorphism and Dynamic Binding]]
|
||||
[[Property:weight|-4]]
|
||||
[[Property:uuid|1c3221be-0237-1c9a-407d-652a4084de12]]
|
||||
Inheritance is not just a module combination and enrichment mechanism. It also enables the definition of flexible entities that may become attached to objects of various forms at run time, a property known as polymorphism.
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
[[Property:title|14 Putting a System Together]]
|
||||
[[Property:link_title|I2E: Putting a System Together]]
|
||||
[[Property:title|I2E: Putting a System Together]]
|
||||
[[Property:weight|-1]]
|
||||
[[Property:uuid|97460714-8ae1-a7cb-8216-235827045ea6]]
|
||||
We have now studied the constituents of Eiffel software. It remains to see how you can combine these elements into executable '''systems''' (the Eiffel concept closest to the traditional notion of program) and libraries.
|
||||
|
||||
@@ -1,12 +1,11 @@
|
||||
[[Property:title|5 Types]]
|
||||
[[Property:link_title|I2E: Types]]
|
||||
[[Property:title|I2E: Types]]
|
||||
[[Property:weight|-10]]
|
||||
[[Property:uuid|344a9fdc-3346-5e2d-5fdd-77464e92f72f]]
|
||||
Eiffel is strongly typed for readability and reliability. Every entity is declared of a certain type, which may be either a reference type or an expanded type.
|
||||
|
||||
Any type <code>T</code> is based on a class, which defines the operations that will be applicable to instances of <code>T</code>. The difference between the two categories of type affects the semantics of an entity <code>x</code> declared of type <code>T</code>: for a reference type, the most common case, possible values for <code>x</code> are references to objects; for an expanded type, the values are objects. In both cases, the type rules guarantee that the objects will be instances of <code>T</code>.
|
||||
|
||||
A non-expanded class such as <code>ACCOUNT</code> yields a reference type. As a result, an entity of type <code>ACCOUNT</code>, such as <code>acc</code> in the earlier client example (see the declaration of <code>acc</code> and the accompanying picture as given in [[4 Classes|section 4]] ), denotes possible run-time references to objects of type <code>ACCOUNT</code>.
|
||||
A non-expanded class such as <code>ACCOUNT</code> yields a reference type. As a result, an entity of type <code>ACCOUNT</code>, such as <code>acc</code> in the earlier client example (see the declaration of <code>acc</code> and the accompanying picture as given in [[I2E: Classes]] ), denotes possible run-time references to objects of type <code>ACCOUNT</code>.
|
||||
|
||||
In contrast, the value of an entity <code>acc</code> declared of type <code>expanded ACCOUNT</code> is an object such as the one shown on the figure below, with no reference. The only difference with the earlier figure is that the value of <code>acc</code> is now an <code>ACCOUNT</code> object, not a reference to such an object. No creation instruction is needed in this case. (The figure does not show the <code>PERSON</code> object to which the <code>owner</code> field of the <code>ACCOUNT</code> object -- itself a reference -- is attached.)
|
||||
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
[[Property:title|What Must I Know First?]]
|
||||
[[Property:link_title|I2E: What Must I Know First?]]
|
||||
[[Property:title|I2E: What Must I Know First?]]
|
||||
[[Property:weight|-14]]
|
||||
[[Property:uuid|f40b4a30-87f7-2c27-b6e7-ef2f2a74661b]]
|
||||
This Invitation assumes that you have some experience of software development, but that's all. Previous exposure to object technology is not required. If you've had it, it will help; but if it has all been to notations like UML or programming languages like C++ and Java, you should not let it guide your study of this Invitation. Although Eiffel shares a number of properties with these other approaches, it takes a fresh path to object technology, based on a small number of simple, far-reaching concepts.
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
[[Property:title|Invitation to Eiffel]]
|
||||
[[Property:title|Invitation to Eiffel (I2E)]]
|
||||
[[Property:link_title|Invitation to Eiffel]]
|
||||
[[Property:weight|-15]]
|
||||
[[Property:uuid|7a606387-2653-b122-b4ef-e283a389656e]]
|
||||
The Invitation to Eiffel is a short set of pages that should provide you with the essence of the Eiffel way, without taking too much of your time. Enjoy this profoundly different way of thinking about developing software! When you are done, move on to the more detailed Eiffel tutorial.
|
||||
The Invitation to Eiffel (I2E) is a short set of pages that should provide you with the essence of the Eiffel way, without taking too much of your time. Enjoy this profoundly different way of thinking about developing software! When you are done, move on to the more detailed Eiffel tutorial.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user