1 / 27

Elements and Principles of Object Orientation

Elements and Principles of Object Orientation. Elements of OO. Abstraction Encapsulation Modularity Hierarchy: Inheritance & Aggregation 4 major/essential elements 3 minor/helpful elements Typing Concurrency Persistence . Abstraction.

don
Download Presentation

Elements and Principles of Object Orientation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Elements and Principles of Object Orientation

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

  3. 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. Specifies responsibilities of objects of the same kind Focuses on outside view of an object: Behavior/implementation separation collaboration contract Abstraction Defines a contract on which other objects may depend characteristics responsibilities Abstraction Every object collaborates with other objects to achieve some behavior characteristics responsibilities server client

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

  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 A client will not notice it even if its Dog Taunter is replaced. So its client doesn’t need to care about its inner works.

  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. Objects within the same component are closely related 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 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 Use cohesive classes, each focuses on a single topic Not cohesive

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

  25. TheLiskov Substitution Principle • LSP = subtypes must be substitutable for their base types.

  26. TheDependency 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. TheInterface Segregation Principle • ISP = client should not depend upon methods that they do not use.

More Related