Object Oriented Programming Objects • An object consists of • Primary object-oriented language concepts − hidden or private part − dynamic lookup Hidden part ◊ instance variables / − encapsulation feature1 . . . data members − inheritance ◊ possibly, also some private feature2 . . . − subtyping functions • OO program − • Program organization public part − Creates a “root object” − Organize concepts into objects and relationships between them ◊ public operations, or member ◊ which may create other objects − Build program to be extensible functions, or methods, or ◊ which, in turn, may create other “messages” ◊ Both open and closed objects ... ◊ possibly, also some public − Objects • Comparison instance variables ◊ send messages to / invoke − Objects as closures? • In Eiffel terminology: methods on / apply features of features other objects L. Dillon, CSE 452, Fall 2008 1 L. Dillon, CSE 452, Fall 2008 2

What’s interesting about this? Why study Eiffel?

• Universal encapsulation construct • Completely object-oriented approach from start to finish − Flight simulator • Design by contract (DBC) method − File system • Language mechanisms supporting OO and DBC − Database − Classes, objects, assertions, contracts, ... − − Window Single & multiple inheritance with ◊ redefinition − List ◊ undefinition − Integer ◊ renaming − Genericity: contrained & unconstrained • Metaphor usefully ambiguous − Uniform type system: safe covariance − sequential or concurrent computation − Agents (power of functional programming in OO) − “Once” mechanisms − distributed, synchronous or asynchronous communication − Conversions − Unrestricted streaming: files, databases, networks, ... − Full garbage collection L. Dillon, CSE 452, Fall 2008 3 L. Dillon, CSE 452, Fall 2008 4 Goals for Eiffel Some Eiffel principles

• Productivity: faster time to market, fewer developers • Abstraction • Reliability: fewer bugs • Information hiding • Seamlessness • Extensibility: be responsive to customer needs • Reversibility • Reuse: stand on the shoulder of giants • Design by contract • Efficiency: make the best use of hardware resources • Open-closed principle • Single choice principle • Maintainability: spend your time on new developments • Uniform access principle • Command-query separation principle • Option-operand separation principle (Courtesy of http://se.ethz.ch/teaching/2008-H/eiffel-0291/) • Strong style rules • . . . (Courtesy of http://se.ethz.ch/teaching/2008-H/eiffel-0291/) L. Dillon, CSE 452, Fall 2008 5 L. Dillon, CSE 452, Fall 2008 6

Dogmatism Libraries

• Dogmatic where it counts • Fundamental data structures and algorithms − Information hiding, e.g., not allowed: x.a := b − Overloading • Portable graphics − Style rules • Internet, Web − “One good way to do anything.” • Lexical analysis, parsing • Purposely left out − Goto • Database interfaces − Functions as arguments • . . . − Pointer arithmetic − Cryptic symbols, e.g., x++, ++x (Courtesy of http://se.ethz.ch/teaching/2008-H/eiffel-0291/) • Flexible when it makes no point to harass programmers − Syntax, e.g., optional semicolon’s

(Courtesy of http://se.ethz.ch/teaching/2008-H/eiffel-0291/)

L. Dillon, CSE 452, Fall 2008 7 L. Dillon, CSE 452, Fall 2008 8 Eiffel lifecycle model Object-Oriented Software Construction

• Focus on abstractions • Reuse (consumer and producer) • Seamless development • Reversibility All you need is code • Single model principle − The software is the model Code is all you need − The model is the software − The software includes everything relevant to the project --The bOOtles − Tools automatically extract views ◊ analysis model, design, program, documentation, ... • Contracts as a guide to − analysis, design, implementation, maintenance, management, ... (Courtesy of http://se.ethz.ch/teaching/2008-H/eiffel-0291/) (Courtesy of http://se.ethz.ch/teaching/2008-H/eiffel-0291/)

L. Dillon, CSE 452, Fall 2008 9 L. Dillon, CSE 452, Fall 2008 10

Seamless development The cluster method

Single notation, tools, concepts, Example classes at each stage: • Clusters (set of related principles classes) P L A N E, A C C O U N T,... Continuous, incremental • Start with foundational STAT E, C O M M A N D,... development clusters H A SH _TA B L E,... Model, implementation, T E ST_ DR I V E R,... • Mini lifecycles, each documentation are always TA B L E,... covering a cluster consistent • Always a “demo-able” version at any point Reversibility

(Courtesy of http://se.ethz.ch/teaching/2008-H/eiffel-0291/) (Courtesy of http://se.ethz.ch/teaching/2008-H/eiffel-0291/)

L. Dillon, CSE 452, Fall 2008 11 L. Dillon, CSE 452, Fall 2008 12 Mini-lifecycle tasks Language basics

• Specification Language mechanisms supporting OO and DBC − Classes, objects, assertions, contracts, ... • Design / Implementation − Single & multiple inheritance with • Verification & Validation (V&V) ◊ redefinition ◊ undefinition • Generalization ◊ renaming − Genericity: contrained & unconstrained − Uniform type system: safe covariance − Agents (power of functional programming in OO) − “Once” mechanisms − Conversions (Courtesy of http://se.ethz.ch/teaching/2008-H/eiffel-0291/) − Unrestricted streaming: files, databases, networks, ... − Full garbage collection (Courtesy of http://se.ethz.ch/teaching/2008-H/eiffel-0291/) L. Dillon, CSE 452, Fall 2008 13 L. Dillon, CSE 452, Fall 2008 14

Syntax conventions

Semicolon used as a separator (not a terminator) It’s optional almost all the time. Just forget about it!

Style rules include • Every feature should have a header comment • Every class should have an indexing clause • Recommended layout, indentation • Recommended naming conventions for classes, features, etc. • ...

(Courtesy of http://se.ethz.ch/teaching/2008-H/eiffel-0291/)

L. Dillon, CSE 452, Fall 2008 15