1 / 30

Data Abstraction: The Walls

This chapter explores the principles and techniques of object-oriented analysis and design, including encapsulation, inheritance, and polymorphism. It also discusses the importance of high cohesion and loose coupling in software modules.

sbrady
Download Presentation

Data Abstraction: The Walls

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. Data Abstraction: The Walls Or Techniques for solving large complex problems Chapter 1

  2. Object-Oriented Concepts • Object-oriented analysis and design (OOAD) • Process for solving problems • Solution • Computer program consisting of system of interacting classes of objects • Object • Has set of characteristics, behaviors related to solution

  3. Object-Oriented Analysis & Design • Requirements of a solution • What solution must be, do • Object-oriented design • Describe solution to problem • Express solution in terms of software objects • Create one or more models of solution

  4. Aspects of Object-Oriented Solution Principles of object-oriented programming Encapsulation: Objects combine data and operations. Inheritance: Classes inherit properties from other classes. Polymorphism: Objects determine appropriate operations at execution time.

  5. Software Modules – High Cohesion Low or high cohesion example? function doIt () { readData(L, inputFile) sort(L) print(L) } • Each module should perform one well-defined task • Cohesion refers to the degree to which the elements inside a module belong together. • Benefits of high cohesion • Well named, self-documenting • Easy to reuse • Easier to maintain • More robust

  6. Software Modules – Loose Coupling iPods are a good example of tight coupling: once the battery dies you might as well buy a new iPod because the battery is soldered in place and won't come loose, thus making replacement very expensive. A loosely coupled player would allow effortless battery replacement. http://stackoverflow.com/questions/226977/what-is-loose-coupling-please-provide-examples • Measure of dependence among modules • Dependence • Sharing data structures or calling each other’s methods • Modules should be loosely coupled • Highly coupled modules should be avoided

  7. Coupling • Benefits of loose coupling in a system • More adaptable to change • Easier to understand • Increases reusability • Has increased cohesion Well designed software systems have high cohesion and loose coupling.

  8. Specifications • The task sort is a module separate from the MyProgrammodule • If sort does only the data reordering it is a highly cohesive unit. The program is loosely coupled because the unsorted data is passed as input to sort and the sorted data is returned to MyProgram.

  9. Operation Contracts for Program Modules • What documentation is necessary for a program unit such as the sort function in the previous slide? • Analysis - Documents • How method can be used • What limitations it has • Design and Coding - Specifies • Purpose of modules • Data flow among modules • Pre-, post-condition, input, output of each module

  10. Sort Function Documentation /* Purpose: Sorts in ascending order the input, anArray. Pre: anArray is an array of n integers and 1<=n<MAX_ARRAY_SIZE. Post: anArray[0] <= anArray[1] <= … <= anArray[n-1] and n is unchanged Checks: throws a logic exception if n <= 0 */ void sort(int [] anArray, int n) throws logic_exception;

  11. Unusual Conditions Ways to address invalid conditions: • Assume they will not happen • Ignore such situations • Guess at client’s intentions • Return value that signals problem • Throw an exception

  12. Documentation Abstraction Separate purpose of a module from its implementation Specifications do not indicate how to implement The sort function can be used without knowing implementation – fast or slow sort? In place or extra memory used? Not necessary for correct use.

  13. Information Hiding • Abstraction helps identify details that should be hidden from public view • Ensures no other module can tamper with these hidden details either maliciously or inadvertently. • Isolation of the modules cannot be total, however • Client must know what tasks can be done, how to initiate a task

  14. Information Hiding Tasks communicate through a slit in the wall

  15. Information Hiding A revised implementation communicates through the same slit in the wall and can still be used without changing MyProgram as long as the sort signature does not change

  16. Minimal and Complete Interfaces • Interface for a class is made up of publicly accessible methods and data • Complete interface for a class • Allows programmer to accomplish any reasonable task • Minimal interface for a class • Contains method if and only if that method is essential to class’s responsibilities • You have been assigned the task of implementing a Circle interface – what data are needed? what are the minimal set of functions needed? what other functions might be useful? circle.h

  17. Abstract Data Types (ADT) • Typical operations on data • Add data to a data collection. • Remove data from a data collection. • Ask questions about the data in a data collection. • An ADT : a collection of data and a set of operations on data • A data structure : an implementation of an ADT within a programming language

  18. Abstract Data Types (ADT) A dispenser of chilled water, crushed ice, and ice cubes

  19. Abstract Data Types (ADT) A wall of ADT operations isolates a data structure from the program that uses it

  20. Designing an ADT • Evolves naturally during the problem-solving process • What data does a problem require? • What operations does a problem require? • ADTs typically have initialization and destruction operations • Assumed but not specified at this stage

  21. ADTs That Suggest Other ADTs • You can use an ADT to implement another ADT • Example: Date-Time objects available in C++ for use in various contexts • Possible to create your own fraction objectto use in some other object which requires fractions

  22. The ADT Bag • Consider the bag to be an abstract data type. • We are specifying an abstraction inspired by an actual physical bag • Doesn’t do much more than contain its items • Unordered with possibly duplicate objects • We insist objects be of same or similar types • Knowing just its interface • Can use ADT bag in a program

  23. Identifying Behaviors A (class responsibility-collaboration) CRC card for a class Bag

  24. Specifying Data and Operations (unified modeling language) UML notation for the class Bag

  25. An Interface Template for the ADT LISTING 1-1 A file containing a C++ interface for bags

  26. An Interface Template for the ADT LISTING 1-1 A file containing a C++ interface for bags

  27. An Interface Template for the ADT LISTING 1-1 A file containing a C++ interface for bags

  28. Using the ADT Bag LISTING 1-2 A program for a card guessing game

  29. Using the ADT Bag LISTING 1-2 A program for a card guessing game

  30. End Chapter 1

More Related