Information hiding Receivers and behavior � Messages differ from traditional function � Notice how a user of a service being calls in two very important respects: provided by an object, need only know the a) A designated receiver accepts the message name of the messages that the object will b) The interpretation of the message may be accept. different, depending upon the receiver – They need not have any idea how the actions � Although different objects may accept the performed in response to these requests will same message, the actions ( behavior ) the be carried out. object will perform will likely be different � Having accepted a message, an object is – Might not even know what behavior to perform until run-time – a form of late binding responsible for carrying it out. Elements of OOP – Recursive Elements of OOP - Classes Design � 3. Every object has its own � 4. Every object is an instance of a class. A memory, which consists of class groups similar objects. other objects. – Flo is an instance of the class Florist – The structure of the part mirrors � 5. The class is the repository for behavior the structure of the larger unit. associated with an object. � Principle of non-interference: “ Ask not what you can do to – All objects that are instances of a class use the your data structures, but ask same method in response to similar messages. what your data structures can do for you. ” (Budd) Elements of OOP - Inheritance Levels of abstraction 1 � 6. Classes are � Communities of interacting objects organized into a singly-rooted tree structure, called an inheritance hierarchy – Internally: within the program system � Data and general – And externally: team of programmers, each behavior at one responsible for different parts of the system abstraction level � Focus here is on communication at the extend to lower levels highest level of abstraction – But can override – i.e., lines of communication between the agents behavior (a later topic)
Packages and Namespaces Levels of abstraction 2 � Used to surround a collection of objects (a � Clients and servers – abstraction about the small community in itself) with a layer relationship between two individual objects – Typically one is providing a service, and the other � To control visibility from outside the module is using the service – A form of information hiding – promotes low � Note: not specifically web servers/clients – a coupling, and thus modifiability, reuse potential, more general idea about interacting objects and so on Levels of abstraction 3, 4, … Finding the right abstraction level � 3. Describing services � A critical problem to solve in early stages of development – not easy, and no “right way” – Focus is on a server – Independent of clients – Must determine what details are appropriate at each level of abstraction – i.e., defining the interface – And (often more importantly) must decide what � 4. Implementing the interface – from point details should be omitted – to be considered later of serving the client(s) � Don’t want to ignore important information � … Implementing individual functions, and other background features about which the – But don’t want to manage too much information, clients have no need to know or have excessive information hide critical details Small vs. large programs On to OO design ideas Really just an introduction (much more in CS 48) � Programming in the small: – Usually just one programmer About “ programming in the large ” – He/she understands everything from top to bottom – Major problems are in the development of algorithms � Programming in the large: – System is developed by large team(s) of programmers – Major problems are in the management of details – Communication is vital – between programmers, and between their respective software subsystems
Basis for Design (early stages) Responsibility-Driven Design � Q. What aspects of a problem are known first? � “Understanding responsibilities is key to good object- oriented design” (Martin Fowler) a) Data structures b) Functions � RDD concept: some object (and thus some class) must be responsible for every task that has to be accomplished by c) Formal specifications the system d) Behavior � RDD is an Agile design technique � A design technique based on behavior can be � Accounts for ambiguous and incomplete specifications applied from the very beginning of a problem � Naturally flows from Analysis to Solution. – Other aspects (the structural properties) necessarily � Easily integrates with various aspects of software development require more preliminary analysis Example: designing the Intelligent RDD activities – focus on behavior Interactive Kitchen Helper (IIKH) � First identify and describe the behavior � Imagine the boss rushes of the entire application in with his specifications – What the system must do for your team ’ s next – In what ways the system will interact project … carefully with actors (users, other systems, …) drawn on a napkin � Refine this overall behavior into � Briefly: the system is behavioral descriptions for subsystems intended to replace that box of index cards of � Translate the behavior descriptions recipes in many kitchens into code IIKH system behavior Describing use cases � Browse a database of recipes � Idea: Pretend we already had a working application - walk through the various uses � Add a new recipe to the database of the system � Edit or annotate an existing recipe � Use Case vs. Scenario: � Plan a meal consisting of several courses – A scenario is a specific use case instance � Scale a recipe for some number of users � Goal is to make sure we have uncovered � Plan a longer period, say a week all the intended uses of the system � Generate a grocery list that includes all the � Also helps establish and comprehend the items in all the menus for a period “ look and feel ” of the system IIKH use cases?
Software components CRC cards � A software component is simply an abstract design � Records name, entity with which we can associate responsibilities responsibilities, for different tasks and collaborators � May eventually be turned into a class, a function, a of a component module, or something else � Design principles: � Inexpensive – A component must have a small, well-defined set of � Erasable responsibilities � Physical – A component should interact with other components to the minimal extent possible What good are they? Identifying components Component identification in RDD � With OOP, mostly asking “ What types of � As we walk through scenarios, we go through cycles of identifying a what, followed by a who objects will make up the system? ” – What action needs to be performed at this moment? � Carefully study the problem (especially – Who is the component that is charged with performing requirements and use cases) to find out the action? – Candidate classes: nouns in the problem � Every what must have a who , otherwise it simply � Some are data – will be treated as class attributes will not happen. � Most are participants in the solution – agents! � Postpone decisions about specific GUI details, algorithms, … – keep to major responsibilities – Operations: verbs in the problem Identifying IIKH components Assigning responsibilities: Greeter � The analysis team (author Budd …) decides the � Operations? major responsibilities divide naturally into two – Greet user groups – Offer choices – Recipe database – browsing, reviewing/editing recipes – Pass control – Menu plans – creating/reviewing plans for meals � Data? � Team also decides to include a component called a Greeter to present an attractive window, and � Collaborators? allows the user to select from the various choices – Recipe Database – Idea is that this component will pass on tasks to either – Planner a recipe database object or a menu planner object
Recommend
More recommend
