![]() |
|
|||||
Frequently Asked Questions on the Eiffel LanguageClassic EiffelWhat is Eiffel?Where does the name come from?How did Eiffel come about, and what is its history?What is EiffelStudio™?Ok, so what is the difference between Eiffel and EiffelStudio?Is Eiffel intended for any specific application area?What about operating systems then? Where does Eiffel run?Won't I have to forsake my existing software thus losing millions of dollars?How fast is Eiffel's run-time performance?What is Melting Ice Technology?Is it true that Eiffel compiles into C?What about graphics?What about relational databases?What does the IDE look like?What does an Eiffel program look like?What does a class look like?A counter is great but how do I write a real system?What about reusability?Assertions look great, but how do they help me?What about repeated inheritance?Tell me about typing and bindingWhat is BON?What is this Design by Contract™ mechanism, and how will it change my life?What can Eiffel bring to me that other languages such as C++, C#, and Java cannot?How long will it take to learn Eiffel?What is multiple inheritance?Why is multiple inheritance so clean in Eiffel?What is concurrent engineering?What is genericity?Eiffel for .NETIs Eiffel transparent in .NET?How does Eiffel for .NET produce reusable components?I have a several classes in VB.NET and C# do I need to rewrite them in Eiffel?What UML tools does Eiffel support?How do you create a web service in Eiffel?Classic Eiffel Questions
|
|
Actually we like to talk about "systems" -- a set of classes -- each covering a "data abstraction" -- a certain set of objects from the external world or from the implementation. For example, you may have classes AIRPORT, RADAR and RUNWAY in a flight control system, classes CUSTOMER and ACCOUNT in a banking system. In any system you can also have general-purpose classes such as LINKED_LIST and HASH_TABLE, although you would not normally write them but reuse them from a library such as EiffelBase.
Here is the outline of a simple class COUNTER describing a counter:
indexing description: "Counters that you can increment by one, decrement, and reset" class COUNTER feature -- Access item: INTEGER -- Counter's value. feature -- Element change increment is -- Increase counter by one. do item := item + 1 end decrement is -- Decrease counter by one. do item := item - 1 end reset is -- Reset counter to zero. do item := 0 end end |
At run time this class will have instances: each instance is an object that represents a separate counter. To create a counter you declare the corresponding entity, say
my_counter: COUNTER
|
create the corresponding object
create my_counter
|
(where create is the object creation operation), and can then apply to it the operations of the class (its features):
my_counter.increment ... my_counter.increment ... my_counter.decrement ... print (my_counter.item) |
Such operations will appear in features of other classes, called the clients of class COUNTER.
If you understand this example, you already know a fair deal of Eiffel! Note how simple the syntax is. Semicolons between instructions are optional (they have been omitted above); no strange symbols, no complicated rules.
A couple more comments about this example: all values are initialized by default, so every counter object will start its life with its value, item, initialized to zero (you don't need to call reset initially). Also, `item' is an attribute, which is exported in read-only mode: clients can say
print (my_counter.item) |
but not, for example,
my_counter.item := 657 |
which would be a violation of "information hiding". Of course, the class author may decide to provide such a capability by adding a feature
set (some_value: INTEGER) is -- Set value of counter to some_value. do item := some_value end |
in which case the clients will simply use
my_counter.set (657) |
But that's the decision of the authors of class COUNTER: how much functionality they provide to their clients.
The indexing clause at the beginning of the class does not affect its semantics (i.e. the properties of the corresponding run-time objects), but attaches extra documentation to the class. Such information can be used to help developers search for reusable classes. It is good practice to include at least a description entry providing an informal description of the purpose of the class.
The principles scale up. A class can represent a counter, but it can also represent an assembly line or a factory.
The Eiffel mechanisms for abstraction, reliability, and simplicity provide a power of expression unmatched in the software world.
As Roland Racko wrote in Software Development:
"Everything about Eiffel is single-mindedly, unambiguously, gloriously focused on reusability -- right down to the choice of reserved words and punctuation and right up to the compile time environment".
We couldn't have said it better. Eiffel was designed from day one to be the vehicle for the new software industry, based on the reuse of high-quality components -- rather than on everyone reinventing the wheel all the time.
This saves organizations countless hours and thousands of dollars in wasted development time.
Eiffel has put these ideas into practice by providing a rich set of professional reusable libraries (several thousand carefully crafted classes): EiffelBase, EiffelVision, EiffelNet, EiffelWeb, EiffelParse, EiffelLex, WEL, MEL, PEL etc.
Assertions radically improve the nature of software development. They have three major benefits:
indexing description: "Counters that you can increment by one, decrement, and reset" class interface COUNTER feature -- Access item: INTEGER -- Counter's value. feature -- Element change increment is -- Increase counter by one. ensure count_incresed: item = old item + 1 decrement is -- Decrease counter by one. require count_not_zero: item > 0 ensure count_decreased: item = old item - 1 reset is -- Reset counter to zero. ensure counter_is_zero: item = 0 invariant positive_count: item >= 0 end |
In EiffelStudio, you get the short form at the click of a button. The short form is an ideal form of documentation, abstract yet precise. Best of all, it is produced automatically by the environment, not written separately, so you don't need to do any work to get it! No need to write "interface modules" and then repeat their information in the implementation part.
Repeated inheritance is the case (illustrated by the figure below) in which a class inherits from another through two or more paths. Only in Eiffel can you decide separately for each feature of the common ancestor, such as `birth_date' or `library_privileges' in the example, whether it gives one feature or two in the repeated descendant. In the figure, a teaching assistant has the same birth date whether viewed as an instructor or as a student (one feature), but has different library privileges under each of these capacities (two features). This flexibility is indispensable to specify what you want to share and what you want to replicate.
|
Eiffel is statically typed to ensure that errors are caught at compile time, not run time. For example if your system may mistakenly try to execute a request to compute the diagonal of a graphical object that happens to be a triangle, the Eiffel compiler will catch the error before it has had time to cause any damage. Most other object-oriented languages use some degree of "dynamic typing" in which such errors can escape the compiler. (Beware in particular of C extensions that are sometimes advertised as statically typed but still permit almost arbitrary type conversions.)
Eiffel is dynamically bound to guarantee that the right version of an operation will always be applied depending on the target object. For example if you apply the feature "take off" to an object representing some kind of plane, you have the guarantee that if there are several plane types, each with its own `take_off' feature, the appropriate one will always be automatically selected. (In contrast, some approaches by default use "static binding", which can result in disastrously incorrect behavior.)
BON is the acronym for Business Object Notation, an analysis and design method that is based on concepts close to those of Eiffel (seamlessness, reversibility, contracting) and defines simple, intuitive graphical conventions. BON is particularly notable for its ability to scale up when you need to describe large and complex systems, keeping a view of the whole while zooming into the details of components at various levels of abstraction. EiffelCase, the Diagram Tool of EiffelStudio, supports BON. The method is described in the book, "Seamless Object-Oriented Software Architecture", by Kim Walden and Jean-Marc Nerson, that is available online.
Design by Contract (DbC) is a unique mechanism that supports the production of quality software. It ensures that your code will have substantially less errors because it follows 'the rules' of development. Our customers tell us that thanks to DbC they cut the number of bugs, reduce testing costs, and quicken time to market.
Clean clear syntax, reusability, native Design by Contract, support for the full software lifecycle, portability, openess ... In short, the ability to finish projects on schedule and enhanced productivity in all stages of development.
With simple and easy to read syntax, Eiffel is intuitive and user friendly. It takes 4-7 days on average to become comfortable with the language and not much more to master the environment. To get a head start with Eiffel, visit the Presentation page.
Multiple inheritance is an mechanism whereby a software unit, known in Eiffel as a class, may inherit the features of many other classes. Most modern programming languages support single inheritance whereby a class can inherit from only one other class, but multiple inheritance offers the developer unrestricted inheritance through the ability to inherit as many as is desired. Using multiple inheritance brings the following advantages: improved reuse, better overall system design and architecture, greater flexibility, easier maintainability and debugging.
Eiffel tames the power of multiple inheritance through a renaming mechanism that eliminates name clashes, and through a selection facility to remove any ambiguities resulting from multiple redeclarations. Without multiple inheritance, you would lose much of the reusability benefits of the object-oriented method. For example, not all comparable elements are numeric (think of strings) and not all numeric elements are comparable (think of matrices). Without multiple inheritance, you would not be able to select one of these properties when you need to or both when required.
Concurrent engineering allows the use of EiffelStudio to automatically generate BON diagrams to see and interact with the overall design of your system as you engineer it.
Genericity is the support for type-parameterized class modules in the software text. In object-oriented circles these are known as generic classes. Such classes use generic parameters in the software text, which are then substituted for formal parameters when the class is actually used by a client class. The benefits of such a method is most fully realized in classes when you consider container objects such as arrays and lists. These types are designed to hold a number of arbitrary elements. Ideally, these contained elements should be able to be any type of element, from books to customers to any type available in your system. Otherwise, you would have to write a separate class definition for every type of element you wish to store, a painful and time consuming activity. Genericity solves this problem by assuming a generic type, which will be substituted by the actual type at runtime.
Yes. Eiffel for .NET can be used in exactly the same way as classic Eiffel and no extra language constructs are required to produce applications.
Eiffel brings quite a few unique and powerful features to .NET. Most noticeably it is the only .NET language to offer multiple inheritance and genericity since the first version of the .NET Framework. These two mechanisms are an indispensable aid to creating fully reusable software in a truly object-oriented way.
Eiffel for .NET also brings the full benefits of Design By Contract, ensuring correctness of the software text, reliability, and robustness. Whilst some other .NET languages do support contract mechanisms, Eiffel for .NET is the only one to support them natively, as an actual language construct.
Eiffel also brings some existing libraries to .NET, so aside from being able to use other .NET libraries such as Windows.Forms for graphical elements you could instead use Eiffel's WEL or EiffelVision2 libraries. EiffelVision2 is a particularly unique graphical library since it is multi-platform, thus ensuring that the compiled system will produce the same display and behavior on all supported platforms.
Eiffel for .NET produces reusable components simply by compiling to the Common Intermediary Language (CIL) code which makes it available for use by any other .NET supported language. However, this method of reuse is only one type of reuse in action, namely the reuse of software components. There are many other levels and areas of potential reusability.
The Eiffel compiler can also produce the so-called 'precompiled libraries' that can then be reused from another Eiffel project. The advantages of using a precompiled library over just referencing an assembly include the ability to reuse native Eiffel constructs (such as multiple inheritance and genericity) without having to recompile the whole source.
The Eiffel language was developed with such levels of reuse in mind from the very beginning and these can benefit the developer in many ways. Multiple inheritance and genericity provide reuse within the actual software implementation, eliminating the need to repeat the same code in different classes - if you need the functionality provided by a class then become a client or inherit from it. Likewise if much of your code does similar things with only small variations you can abstract it into a class or library. This practice is employed and can be seen in the reusable libraries provided with EiffelStudio or Eiffel ENViSioN!.
No. Any code written in a .NET supported language such as VB.NET, C# or Eiffel for .NET automatically compiles to the Common Intermediary Language (CIL) code. Through this standard, independent modules are created (.dll's or .exe's) that are fully interoperable so that a developer can reuse any code without having to rewrite or port it to another language.
EiffelStudio is capable of generating XMI (XML Metadata Interchange) information for any Eiffel system. The XMI notation makes it possible to exchange system information between any products which support this standard (e.g., IBM's Rational Rose).
Creating a web service using Eiffel for .NET is as simple as creating one in any other .NET supported language. The class that contains the methods you wish to expose on the Internet can inherit from the .NET type System.Web.Services.WebService.
To expose class features on the Internet they must then be given custom attributes declaring them as web methods.
About Eiffel SoftwareEiffel Software (a division of ISE) is the world leader in Eiffel pure object-oriented programming tools. Founded in 1985, Eiffel Software produces proven professional tools and component libraries for business-critical and enterprise software developments. Eiffel Software's products enable their customers to output more and higher-quality software in less time than with any other development tools available. Its users span the globe, in industries ranging from large financial institutions to technology manufacturing, government and defense contractors, health care providers and more. |
|
© 1985-2008 Eiffel Software. All rights reserved. -- Privacy Policy |