1. Object-Oriented Approach Both the problem and its solution is represented as a collection of objects that unify data and behavior descriptive of entities involved. Objects are subject to classification based on shared traits or similar characteristics. Hence each object can be an instance of a class.

2. Object Hierarchy, Base Classes Classes are often organized in a hierarchy with one or more base classes serving as roots of hierarchal relations. Subclasses are derived from base classes (aka superclasses). A derived class inherits all the features of the base class, but can introduce its own specifics or deviations from the original behavior.

3. Abstract Classes, Polymorphism Abstract class: a class that cannot be instantiated directly, it can only serve as a basis for deriving subclasses. Interface: “distilled” abstract class (no implementation details whatsoever). Behavior: action or transformation an object can perform or be subjected to (can be expressed as a collection of methods and events). Polymorphism reflects the fact that subclasses differ among themselves and from the base class.

4. Benefit of Objects Abstraction: makes difficult concepts look simple Encapsulation: hides unnecessary detail Polymorphism: allows for specialization of general behavior Do objects really make the expression of your process / problem simpler?

5. OO Solution If you can express your problem or process in terms of objects and interrelations among them you have an abstract OO solution. Good OO design is such that it makes this OO solution look simple. Then coding amounts to filling in blanks in method and property implementations.

6. OO Example: Email Validation Problem: Validate email address Solution: Define Email class that has an IsValid() method. E.g. if ( Email(“max@ultramax.com”).IsValid() ) … And you are done! But what does IsValid() do??

7. Email: OO Decomposition Email is comprised of LocalPart and Domain. Email is valid when: -It can be parsed into LocalPart and Domain -and when both are valid. Email => LocalPart@Domain bool Email::IsValid() { return Parse() && LocalPart.IsValid() && Domain.IsValid(); } * Email class needs Parse() method LocalPart and Domain member classes.

8. Domain: OO Decomposition Email is comprised of LocalPart and Domain. Email is valid when: -It can be parsed into LocalPart and Domain -and when both are valid. Email => LocalPart@Domain bool Email::IsValid() { return Parse() && LocalPart.IsValid() && Domain.IsValid(); } * Email class needs Parse() method LocalPart and Domain member classes.

9. Subdomain and TLD Relation TLD is a special case of Subdomain. Namely TLD is a subdomain to which additional validation rules apply (e.g. the list of TLD values is determined by ICANN). Therefore these objects are related. In fact Subdomain is a base class for TLD. TLD::IsValid() is inherited and overriden: bool TLD::IsValid() { return Subdomain::IsValid() && InIcanList(); }

10. Email: Fill In the Blanks Implement Email::Parse(), Domain::Parse(), Subdomain::IsValid(), TLD::InIcannList(). But even with these methods blank you have an abstract solution that is correct in principle and easy to grasp.

11. Use Cases: Tool of OO Design Pertain to requirement elicitation, help understand the way system/object us used. Use cases describe a dialog between an object and an actor, which could be a user, a device or an external system. Use cases can be expressed graphically (e.g. via UML) or textually as “scenario scripts”. In principle a requirement for any process can be given as a comprehensive collection of use cases. When the system is complete the use cases can provide a basis for acceptance testing.

12. Use Cases Diagrams Actor: entity interacting with object Use Case: depiction of functionality Extension: extends the case to illustrate a different or deeper perspective Use: application / re-uses of the already-defined case.

13. Use Cases Diagram Example Start by listing a sequence of steps a user might take in order to complete an action. For example a user placing an order with a sales company might follow these steps: Browse catalog and select items Call sales representative. Supply shipping information. Supply payment information. Receive conformation number from salesperson

14. Use Cases Questions What actors pertain to the use the object? What actors / systems are needed for the object to perform its functions? What external systems send / receive information to / from the object? Answering these helps make the use cases complete.

15. Use Cases Checks Is the terminology consistent? I.e. does everyone use the same terms to describe the same entity, actor or action? Do the activities match perspectives and are they consistent? Are the interactions clear and complete? Are there missing interactions? Are there any redundant activities or actors? Is it clear where each activity starts and ends?

16. OO System Design After identifying entities (object candidates) in requirements and expressing their interrelations via use cases we need to see what entities share common characteristics. Then we can express these common traits in a base class. However, it is conceivable that the identified objects are too dissimilar. But we still can go with OO design as long as the functionality we identified is tightly coupled to the objects.

17. OO System Design, cont’d Actions documented in use cases and in specifications are good method candidates. Permanent data and state information are properties candidate.

18. Object Relationships Association: classes appear together, and the relationship is preserved for some time. Aggregation: one class is a part (i.e. member) of another class. Dependency: changes to the definition of one class affect the other (not a good idea for classes, OK for packages).

19. OO Program Design First Steps: 1)Declaring classes outlined in specification 2)Declaring methods according to interface specification 3)Building an abstract solution operating with empty methods and incomplete classes 4)Making sure that your abstract solution is correct in principle and 5)Filling the blanks (method implementations)

20. OO Program Design, cont’d Filling in the blanks: Creating additional (utility) classes that are not described in specification Creating additional (private) methods and (private) data members Implementing solution in a hierarchal way providing more and more implementation details with each step.

21. OO Program Design, cont’d Finding and Resolving Problems: -You may be using previously developed (e.g. reusable) or 3 rd party objects that are not fully compatible or require modification / tuning – Drop reusable code? Modify design? -You may discover that object interfaces listed in specification are inadequate or inconvenient and need modification – amend spec -You may find inconsistencies or omissions in specification (as well as flaws in the requirements) - amend spec / requirement

22. OO Program Recommendations -Use private to hide all you can -Provide get-accessors for read-only properties -Indicate const methods and mark read-only parameters as such -Avoid using output parameters (use return values instead) -Try to minimize state information in favor of passing additional parameters -Use static (early) binding in favor of late -Throw exceptions in favor of error codes -Never use global objects / global variables -Always follow consistent and predictable coding patterns -Workout a reusable framework if working on similar projects

23. Data Management Design How do you store and recover persistent objects? We may need a data model (and a data modeler as well as database administrator in developer team). Relational data always needs to be properly constrained!

24. Asynchronous Tasks Is our process event driven or time driven? Or is it sequential? If our process is event driven and involves communicating object state changes there are two approaches: -Global Observer: monitors state changes of all objects involved and issues notifications for dependent objects -Concrete Observer: each object monitors its own subject

25. OO Design Measures Provide numeric measure of qualities of your OO design in order to optimize: -Number of base classes -Density of utility classes -Specialization Index: SI = Overridden*level/methods -Methods per class -Weighted methods per class (account for code length-complexity) -Levels of inheritance -Lack of cohesion

26. Reading Chapter 6 in Pfleeger; Chapter 10 in my book.