2. Elements of OO Abstraction Encapsulation Modularity Hierarchy: Inheritance & Aggregation 4 major/essential elements3 minor/helpful elements Typing Concurrency Persistence

3. collaboration contract Abstraction An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provides crisply defined conceptual boundaries, relative to the perspective of the user. Focuses on outside view of an object: Behavior/implementation separation Specifies responsibilities of objects of the same kind Abstraction characteristics responsibilities Defines a contract on which other objects may depend Abstraction characteristics responsibilities client server Every object collaborates with other objects to achieve some behavior

4. Abstraction perspective of the user essential characteristics kinds of objects crisply defined conceptual boundaries

5. Encapsulation Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation. Works hand-in-hand with abstraction: For abstraction to work, implementations must be encapsulated. Intelligent encapsulation localizes design decisions that are likely to change.

6. Encapsulation So its client doesn’t need to care about its inner works. A client will not notice it even if its Dog Taunter is replaced.

7. Modularity Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules. The essential method that we use to manage complexity is “divide and conquer” The OOA process leads to a set of abstractions used in the domain. The OOD process leads to a set of program modules that can be compiled separately, but which have connections with other modules. Modules: - Conceptual breakdown of a system: subsystems, components, objects - Physical containers of program: packages, classes, etc Objects are too tiny and can hardly be used alone Objects within the same component are closely related Objects within the same component are loosely related

8. Modularity

9. Modularity – a real world example + + + Highly cohesive components Loosely coupled components

10. Cohesion & Coupling

11. Hierarchy Hierarchy is a ranking or ordering of abstractions. The two most important hierarchies in a complex system are its class structure (the “is-a” hierarchy) and Its object structure (the “part-of” hierarchy) Class structure (generalization/specialization) Object structure (aggregation/composition)

12. Generalization/Specialization

13. Aggregation/Composition

14. Typing Typing is the enforcement of the class of an object, such that objects of different types may not be interchanged, or at the most, they may be interchanged only in very restricted ways. An object-oriented language can be strongly typed, weakly typed, or even untyped. An object-oriented language can support dynamic typing (or binding) or only static typing (or binding). Benefits of strong typing: -Prevents programs from “crashing” mysteriously -Early error detection is extremely valuable -Helps to document programs -Helps compilers generating more efficient object code Polymorphism, made possible by late binding, is the most powerful feature of OOP languages next to their support for abstraction; and is a central concept in OOD.

15. Typing

16. Concurrency Concurrency is the property that distinguishes an active object from one that is inactive. Physical concurrency – using multiple CPUs. Vs. Illusionary concurrency – using a single CPU with time-slicing. Heavyweight concurrency – using multiple processes. Vs. Lightweight concurrency – using multiple threads within a single O/S process. Whereas OOP focuses on data abstraction, encapsulation, and inheritance, concurrency focuses on process abstraction and synchronization. Each object (drawn from an abstraction of the real world) that represents a separate thread of control is called active.

17. Concurrency

18. Persistence Persistence is the property of an object through which its existence transcends time (i.e., the object continues to exist after its creator ceases to exist) and/or space (i.e., the object’s location moves from the address space in which it is created).

19. Persistence

20. Principles of OOD The Single-Responsibility Principle (SRP) The Open-Closed Principle (OCP) The Liskov Substitution Principle (LSP) The Dependency-Inversion Principle (DIP) The Interface-Segregation Principle (ISP)

21. Design Smells Poor design smells, like a plastic sack of 12-day old kitchen garbage Rigidity = Hard-to-change: changing one place cause never-ending succession of changes. Fragility = A change to one part of the system causes it to break in many other, completely unrelated, parts. Immobility = Hard to disentangle the system into units (or components) that can be reused in other systems Viscosity = The development environment is held together with duct tape and library paste. It takes forever to go around the edit-compile-test loop.

22. Design Smells (cont’d) Needless Complexity = There are a lot of very clever code structures that are not actually necessary right now, but could be very useful one day. Needless Repetition = The code looks like it was written by two programmers named Cut and Paste. Opacity = Elucidation of the originator’s intent presents certain difficulties related to convolution of expression. Mismanaged dependencies Spaghetti code

23. The Single Responsibility Principle SRP = A class should have only one reason to change. Violation of SRP Not cohesive Use cohesive classes, each focuses on a single topic

24. The Open-Closed Principle OCP = Software entities (classes, modules, functions, etc) should be open for extension, but closed for modification.

25. The Liskov Substitution Principle LSP = subtypes must be substitutable for their base types.

26. The Dependency Inversion Principle DIP = High-level modules should not depend upon low-level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

27. The Interface Segregation Principle ISP = client should not depend upon methods that they do not use.