Object-Oriented Software Development Introduction PDF

Object-Oriented Software Development Introduction Housekeeping • • Info • OLAT • • • Handouts Lecture recordings Infos and links Exam • • • Onsite, 10.1.2024, 14:00 - 16:00 Deadline for sign-up/-o : 10.10.2023 end of day Closed book, no retake • Literature: will be published for each...

Object-Oriented Software Development Introduction Housekeeping • • Info • OLAT • • • Handouts Lecture recordings Infos and links Exam • • • Onsite, 10.1.2024, 14:00 - 16:00 Deadline for sign-up/-o : 10.10.2023 end of day Closed book, no retake • Literature: will be published for each chapter • Feedback? • Instant feedback preferred, OLAT or by email: bruno.schae er (at) uzh.ch ff Object-Oriented Software Development – Introduction f ff Dr. Bruno Schä er © 2023 2 Background ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 3 Contents Chapter 1: Introduction Chapter 2: Principles Chapter 3: Class Libraries Chapter 4: Design Patterns Chapter 5: Testing Chapter 6: Refactoring Chapter 7: Frameworks ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 4 Learning Objectives • • Knowledge and understanding of main concepts • • • • • • • • • Objects, classes, inheritance Subclass vs. subtype Class design SOLID principles Design patterns Abstract coupling Dependency injection Refactoring principles Framework principles Application of object-oriented principles • • Object-oriented design Design patterns ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 5 Contents • • • Motivation • Software engineering challenges A short history • From Sketchpad to Java Principles • • • • Objects Classes Inheritance Dynamic binding ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 6 Software Development Challenges • • • • • • • • • • • People & Skills Management Complexity & Volume Time to Market Software Architecture Productivity Software Quality Con guration Management System Integration Sustainability & Evolution of IT Systems Globalization Platform diversity ff fi Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 7 Complexity Essential Complexity • • • Imposed by functional and non-functional requirements Experience and technology may help to cope with it (but not reduce it) Unavoidable Accidental Complexity • • • Introduced by mistake (we didn’t know better) Manifests itself in poor architecture, design, processes Avoidable Incidental Complexity • • • Introduced by intention (over-engineering) Result of not striving for simplicity Avoidable ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 8 How the Brain Masters Complexity Cognitive Mechanisms Chunking Hierarchies Schemata Modularity Inheritance / Layering / Abstractions Patterns Object-Oriented Design Carola Lilienthal: Sustainable Software Architecture. Analyze and Reduce Technical Debt, 2019 ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 9 Sustainability & Evolution • IT systems live way longer than expected • Replacing a large software system is hugely expensive and risky • Rebuilding from scratch is a rare opportunity (?) • Software components have di erent life expectancy (e.g. UI vs. DB) • How to cope with paradigm shifts? • Software stacks keep evolving ever faster • • Software system may comprise competing technologies Evolvable systems • • • • Only systems which don’t have to be comprehensive and perfect with the rst release are likely to succeed Start with an MVP Incremental-iterative development Adapt systems to new requirements (functional and non-functional) fi Object-Oriented Software Development – Introduction ff ff Dr. Bruno Schä er © 2023 10 Je Sutherland: Three Laws of Software Development So ftw Software Developer Softw ar an e d d ev ne elo ve p r f me ul n ly t i un s u de np rs re to di od ct a are is cons traine c o m d by struc muni catio the ture o n f an o rgani zatio n e h t t ha w w t o i n e k e s ’t n y o e d h t s l r i t un Use t n a yw bl ff ff Dr. Bruno Schä er © 2023 e Object-Oriented Software Development – Introduction 11 A Short History – Sketchpad • • • • Ivan Sutherland’s PhD thesis at MIT (1962) Graphical user interface (GUI) for computer aided design • • • First of it’s kind “High resolution” display Direct manipulation with a light pen Master-Instance concept for graphical objects • • • • Repetitively creating similar objects from scratch proved cumbersome Master: de nes properties Occurrence inherits from its master Changes to a master are propagated to its occurrences ACM Turing Award in 1988 fi ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 12 A Short History – Simula 67 • • Simulation of complex environments • Modeling the reality Simula 67 • • • • • • Developed by Ole-Johan Dahl und Kristen Nygaard at the Norwegian Computing Centre, Oslo Based on Simula I General purpose programming language Major concepts • • • Encapsulation and modularization Activities and processes - Conceptually similar to SketchPad’s master and occurrences Abstract data types Major impact on programming languages such as Smalltalk, C++, Java, … Dahl and Nygaard received the ACM Turing Award in 2001 • Small user community (probably ahead of its time) ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 13 A Short History – Alan Kay • • • • • • Father of object-orientation • • Background in biology Fascinated by cells: • • • encapsulated communicating basic building block of complex organisms Student of Ivan Sutherland Coined the term „object-orientation“ FLEX • Focus on • • Learning device (Picture: Marcin Wichary from S.F., U.S.A. / CC BY ) Personal dynamic media (Meta Medium) Joined Xerox Parc in 1970 ACM Turing Award in 2003 The best way to predict the future is to invent it! ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 14 A Short History – Smalltalk • Xerox Parc • • • • Innovations: • • • • Ethernet Laser Printer Interpress (precursor to Postscript/PDF) Workstation (PC): “powerful” hardware, bitmap display, mouse, Ethernet Nursery of object-oriented programming Research project: e ective computer usage (for education) • • • Time frame: 1971 - 1983 Learning Research Group: Alan Kay, Dan Ingalls, Adele Goldberg Vision: Dynabook (notebook/tablet) Achievements • • • Object-oriented concepts Object-oriented programming language (Smalltalk) Graphical user interface Object-Oriented Software Development – Introduction ff ff Dr. Bruno Schä er © 2023 15 A Short History – Smalltalk ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 16 A Short History – Smalltalk Alan Kay Adele Goldberg Dan Ingalls Byte, Aug. 1981 ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 17 A Short History – C++ and Java • • C++ • • • Conceived by Bjarne Stroustrup at the AT&T Labs (1983) Based on C and in uenced by Simula 67 Most popular oo language prior to Java Java • • James Gosling led the development of Java for the “Green” project (1995) Based on C and in uenced by Objective-C, Smalltalk and Simula 67 fl fl ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 18 A Short History – Seminal Publications • • 1972: Modular Programming • • • • D. L. Parnas: "On the Criteria to be Used in Decomposing Systems into Modules“ Managerial: Smaller separate teams with less communication paths Flexibility: Internal changes to a module do not a ect other modules Comprehensibility: System can be digested in chunks 1983: Abstract Data Types • • • • • A.V. Aho, J.E. Hopcroft, and J.D. Ullman: "Data Structures and Algorithms" • ACM Turing Awards: ADT de nes a set of values and operations (B. Liskov 1974) Equivalence of data structures and algorithms Beyond the types provided by a programming language Micro structure • • J.E. Hopcroft 1986 B. Liskov 2008 Object-Oriented Software Development – Introduction ff ff fi Dr. Bruno Schä er © 2023 19 Object-Oriented Principles • • Must have • • • Objects Inheritance Dynamic binding Nice to have • • Classes Garbage collection ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 20 Objects • Object is an instance of an abstract data type: • • • Structural properties • • State (ideally encapsulated) De nes the set of possible values Functional properties • Object reacts to external requests Objects must be uniquely identi able //Create an object TypeScript let person = { firstName: "Jonathan", lastName: “Pine", name: function (): string { return this.firstName + ' ' + this.lastName; } }; Object-Oriented Software Development – Introduction fi ff fi Dr. Bruno Schä er © 2023 person firstName: “Jonathan” lastName: “Pine” name 21 Objects //Multiple objects let person1 = { firstName: "Jonathan", lastName: “Pine", name: function (): string { return this.firstName + ' ' + this.lastName; } }; let person2 = { firstName: "John", lastName: "Thackery", name: function (): string { return this.firstName + ' ' + this.lastName; } }; person2['middleName'] = "W"; TypeScript person1 firstName: “Jonathan” lastName: “Pine” name person2 firstName: "John" lastName: "Thackery" name person2 firstName: "John" lastName: "Thackery" middleName: "W" name person2.name = function(): string { return this.firstName + ' ' + this.middleName + '. ' + this.lastName; } ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 22 Objects • • Abstract data type is implicit ! no abstraction Creating objects without explicit types is unsustainable • • Object de nition cannot be reused Limited factorization Factorization A fact is de ned only once in a software system. • • DRY Don’t Repeat Yourself Adapting objects individually leads to hardly maintainable code Objects represent values1 • What is more important – values or types? 1 more about objects vs. values in chapter ‘Principles’ fi fi ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 23 Classi cation and Speci cation • Values versus types is a philosophical issue • • • Plato: • • Abstractions (ideally prototypes) are more important than concrete objects Concrete objects are imperfect instances of an abstraction Kant: • • Categories (types) take precedence Categories lter resp. classify the reality and interpret phenomena Typed universes are easier to handle • • • Abstraction reduces complexity (Explicit) types enforce reasoning about similarities and di erences of objects Classi cation and speci cation require (explicit) types ff fi Object-Oriented Software Development – Introduction fi fi fi ff fi Dr. Bruno Schä er © 2023 24 Classes • • • Abstract description of an object • • • Class is an implementation of an abstract data type person1 firstName: "John" lastName: "Thackery" Template for creating objects Promoting encapsulation person2 firstName: "Carrie" lastName: "Mathison" Structural properties (state) • • Individual state (instance variables) person3 firstName: “Jonathan” lastName: “Pine” Shared state (class variables) Functional properties (behavior) • • Instance methods Class methods Person firstName lastName personCounter name ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 25 Commonalities and Di erences • • • • Classes (types) de ne common properties of their instances • • Class as a language construct is not really necessary Prototypes and delegation are an alternative How to capture commonalities and di erences between classes? • Example: teacher is a person, but not every person is a teacher Biologists faced the same problem • Carl von Linné created a hierarchical taxonomy Type hierarchy • • Speci cation of type commonalities and di erences Modeling relations among types • • Specialization (downwards along the type hierarchy, e.g. person -> teacher, student) Generalization (upwards along the type hierarchy, e.g. student, teacher -> person) ff ff ff Object-Oriented Software Development – Introduction fi ff fi Dr. Bruno Schä er © 2023 26 Inheritance • Reuse requires exible adaptation to new contexts • • Components without adaptability are hardly reusable "Copy and Modify" does not work, though • • Person firstName lastName personCounter name Contradicts DRY-principle Leads to unmaintainable software Teacher • • • Ideally: ne granularity in adaptations • • name Implement abstractions or extend implementations Also known as „Programming by Di erence“ De ne a new type based on an existing one without copying or changing it • • Add state / behavior Modify behavior Inheritance (i.e. subtyping) extends assignment compatibility • Conventionally based on name or structure equivalency Object-Oriented Software Development – Introduction ff fl ff fi Dr. Bruno Schä er © 2023 fi role 27 Dynamic Binding • • • • Purpose • Several implementations of a method may exist • e.g. along the type hierarchy • Look up the appropriate method according to the dynamic type • Dynamic binding is a kind of polymorphism Abstraction • • • Person firstName lastName personCounter name Teacher Implementation can be mostly based on (abstract) base classes/interfaces role name Allows to treat similar objects in the same way Knowledge about derived classes is restricted to a few places Substitutability • • Objects of a base class can be replaced by objects of a derived class Liskov Substitution Principle (➜ chapter "Principles") Moving type information and control ow to objects Object-Oriented Software Development – Introduction fl ff Dr. Bruno Schä er © 2023 28 Garbage Collection • • • • Challenge • • • Large number of objects are created at run-time Most of them are released shortly after creation (e.g. local variables) Explicit release is expensive and error-prone! (global view required) Solution • • Run-time support for releasing memory Reliability and e ciency are negatively correlated Advantages • • Enhanced reliability Less e ort for implementation, testing and maintenance Disadvantages • • • Run-time and memory impact Limited suitability for realtime systems Integrating systems without garbage collection? ffi ff ff Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 29 OO Concepts in Java • • • • Object • Instance of a class Class • • • • Instance variables Class variables Shape s = new Shape(); public class Shape { Rectangle bounds; static Rectangle sMinSize(); public void draw(Graphics g) {…} public static void setMinSize(Rectangle r) {…} Instance methods Class methods Inheritance } public class Box extends Shape {…} Dynamic binding • • All instance methods are dynamically bound Exception: nal methods fi ff Dr. Bruno Schä er © 2023 Shape b = new Box(); b.draw(); Object-Oriented Software Development – Introduction 30 Glossary • • • Static vs. dynamic type • • Static type: De ned by declaration Dynamic type: De ned by the type of a referenced object at run-time Factorization • • A fact is de ned only once in a software system DRY: Don’t Repeat Yourself Principle of Substitutability (Liskov Substitution Principle) • An object of class T can always be substituted by an object of class T’ where T’ is derived from T fi ff fi fi Dr. Bruno Schä er © 2023 Object-Oriented Software Development – Introduction 31 Literature and References • Literature: • • • •• B. Eckel: On Java 8 B. Meyer: Touch of Class D. Flanagan: Java in a Nutshell Picture credits O. Dahl & K. Nygard: http://www.i .uio.no/~kristen/FORSKNINGSDOK_MAPPE/F_NR_1960.html • • • • • • • • • DynaBook: http://www.computerhistory.org/revolution/mobile-computing/18/315/1683 Xerox Alto: http://www.righto.com/2017/10/the-xerox-alto-smalltalk-and-rewriting.html Smalltalk Desktop: http://www.righto.com/2017/10/the-xerox-alto-smalltalk-and-rewriting.html Byte 8-81: http://www.math.rsu.ru/smalltalk/images/byte.gif Adele Goldberg, Dan Ingalls: http://www.smalltalk.org/ Alan Kay: http://www.aes.org/technical/images/Alan_Kay_Photo.jpg B. Stroustrup: http://www.research.att.com/~bs/homepage.html J. Gosling: http://www.apple.com/pro/science/gosling/ Cognitive Mechanisms: Carola Lilienthal: Sustainable Software Architecture. Analyze and Reduce Technical Debt, 2019 Object-Oriented Software Development – Introduction fi ff Dr. Bruno Schä er © 2023 32