OOD teaches a complicated method, best for large systems. Here we teach the ten cent version. OO Design for the Rest of Us 1

Ten Cent Object-Oriented Design Let’s do this. 2

Some (more) things we’d like to be true  I can drive the design from the user stories  The code just “writes itself”  My code will be easy to understand by the team  My code will be SRP and DRY 3

Reminder on SRP and DRY  S ingle R esponsibility P rinciple ( SRP )  Each class should be responsible for one thing (capability, entity, computation, etc.)  Can phrase this as “mind your own business”  object do its own calculations  object should not do calculations for another  Easy to violate this because objects need to be connected to one another  e.g., Events happen as part of Dates  D on’t R epeat Y ourself ( DRY )  Each computational idea should be expressed just once  Violations often the result of  cut-and-paste programming  incomplete class (others have to do calculations for it, which also violates SRP)  But also over-specialization of classes (class = object)

A Concise Theory of Object-Oriented  Object represents a “thing”  person, car, date, …  (not two things, not ½ thing)  Object responds to messages  (method calls)  Things it does to itself (SRP)  That is, other objects ask the object to do something to itself  Objects are “opaque”  Can’t see each others’ data/vars  Messages (calls) are only way to get things done 5

A Concise Theory of Object-Oriented, II  Because objects are completely opaque, we don’t need to know what’s really inside them  Each car object could be implemented with its own unique code  If two cars behave the same, then really should have same code  Otherwise would violate DRY  And a huge amount of coding work  So all cars are made from a common car template  Template = class  The car template is not a car, it’s a “blueprint” for a car  Helps satisfy DRY 6

myCity’s Show Friends on Map Story Rule Write code so that it sounds like the specification. I call this “coding to the specification” Recall that OO theory and SRP dictate objects that:  represent a “thing”  respond to messages about itself This suggests the start of a design process 1.Identify the “things” 2.Identify their messages 3.Assemble into classes 4.Right things call right messages 7 As a user I want see my nearby friends on the map So that I know who to contact for a spontaneous meet-up Given I am logged in And my location is known When my friends are online And my friends’ location is known And my friends are near me Then I see them on the map

myCity’s Show Friends on Map Story, II 1.Identify the “things”  me (previous user story)  friends, friend  map (previous) 2.Identify the messages  me.logged-in (previous)  friend.location-known  friend.location  friend.online  friend.near(me)  friend.image 3.Assemble into classes (TBD) 4.Right things call right messages (TBD) 8 Given I am logged in And my location is known When my friends are online And my friends’ location is known And my friends are near me Then I see them on the map As a user I want see my nearby friends on the map So that I know who to contact for a spontaneous meet-up  Note how messages “sound like” the specification  Plural objects may be list/set of singular  Classes for some objects may already exist  Look for new messages  May find repetitive messages  e.g., location-known vs. location?  maybe location just returns null (or not)  Implied messages  “see them on the map” −> something to see

myCity’s Show Friends on Map Story, III 9 As a user I want see my nearby friends on the map So that I know who to contact for a spontaneous meet-up class Friend { Location location(); // null −> not-known boolean online(); Bitmap image(); } class Friends implements Iterable { Friends online(); Friends locationKnown(); // −> online? } 1.Identify the “things”  me (previous user story)  friends, friend  map (previous, built-in) 2.Identify the messages  me.logged-in (previous)  friend.location-known  friend.location  friend.online  friend.near(me)  friend.image 3.Assemble into classes 4.Right things call right messages (TBD) Given I am logged in And my location is known When my friends are online And my friends’ location is known And my friends are near me Then I see them on the map

myCity’s Show Friends on Map Story, IV 10 class Friend { Location location(); // null −> not-known boolean online(); Bitmap image(); } class Friends implements Iterable { Friends online(); Friends locationKnown(); // −> online? } Given I am logged in And my location is known When my friends are online And my friends’ location is known And my friends are near me Then I see them on the map  This is the hardest part  What thing does something to itself so friends get drawn on map?  Not mentioned in scenario!  Map? Predefined in Android  How about a FriendMap?  A map with added responsibility of drawing my friends  Let’s take a look at this 4.Right things call right messages

myCity’s Show Friends on Map Story, IV 11 class Friend { Location location(); // null −> not-known boolean online(); Bitmap image(); } class Friends implements Iterable { Friends online(); Friends locationKnown(); // −> online? } Given I am logged in And my location is known When my friends are online And my friends’ location is known And my friends are near me Then I see them on the map  This is the hardest part  What thing does something to itself so friends get drawn on map?  Not mentioned in scenario!  Map? Predefined in Android  How about a FriendMap?  A map with added responsibility of drawing my friends  Let’s take a look at this 4.Right things call right messages

myCity’s Show Friends on Map Story, V 12 class Friend { Location location(); boolean online(); Bitmap image(); } class Friends implements Iterable { Friends online(); Friends locationKnown(); // −> online? } Given I am logged in And my location is known When my friends are online And my friends’ location is known And my friends are near me Then I see them on the map class NearbyFriendsMap extends GoogleMap { private Friends friends; private GoogleMap map; NearbyFriendsMap(GMap map, Friends friends); void showNearbyFriends(); // reimplement every GM method so that it re-calls // the method on map. Called delegation. E.g. Marker addMarker(…) { map.addMarker(…); } }  Is a map, plus nearby friend stuff  Dual responsibilities (Map things, Friend drawing)  Huge amount of work (reimplement all methods)  Illegal in Android: GoogleMap is a “final” class!  SRP implies class that just does drawing friends 4.Right things call right messages

myCity’s Show Friends on Map Story, VI 13 class Friend { Location location(); boolean online(); Bitmap image(); } class Friends implements Iterable { Friends online(); Friends locationKnown(); // −> online? } Given I am logged in And my location is known When my friends are online And my friends’ location is known And my friends are near me Then I see them on the map  Basic idea is an intermediary whose Single Responsibility is drawing my friends on the map class NearbyFriendsTracker { private Friends friends; private GoogleMap map; NearbyFriendsTracker(GMap map, Friends friends); void showNearbyFriends(); }  Single responsibility : drawing friends on map!  Don’t have to bunch of “extra” methods  Very similar, despite SRP  Still trying to make code sounds like specification 4.Right things call right messages

UML Diagram: Subclass Approach 14 __NearbyFriendsMap__ - GoogleMap map - Friends friends −−−−−−−−−−−−−−−−− + showNearbyFriends() _________Friends_________ - List friends −−−−−−−−−−−−−−−−− + Friends online() + Friends locationKnown() _GoogleMap_ … _________Friend_________ + boolean online() + Location location() + Bitmap image() * _Iterable_ …

UML Diagram: Middleman Approach 15 _NearbyFriendsTracker_ - GoogleMap map - Friends friends −−−−−−−−−−−−−−−−− + showNearbyFriends() _________Friends_________ - List friends −−−−−−−−−−−−−−−−− + Friends online() + Friends locationKnown() _GoogleMap_ … _________Friend_________ + boolean online() + Location location() + Bitmap image() * _Iterable_ …

Take Aways  Design method combines a few guidelines  find things and messages  pack into SRP classes  make code sound like the specification  Non-trivial, takes experience  plural thing implies singular things  messages that don’t quite work  “Missing” (implied) things and messages  May take multiple tries on harder parts  Very common to revise after the fact (refactor)  New insights, new features benefit from diff. design 16

Take-Aways from Class Today  Object-oriented design is intuitive, but subtle  Java is just a tool, does not guarantee good design  (Just because I have an expensive camera does not make me a good photographer :)  Easy to put functionality in wrong place, make classes too big, or make too small  Possible to diagnosis and repair a design before or after the coding (may require both)  SRP, DRY  Change in one class affects another (SRP)  Small change affects multiple classes or methods  Unfortunately, there are many kinds of design mistakes, and unique repairs for them 17

Good-Enough is the “ 80/20 Rule ”  Returns on engineering investment are not linear  80 percent of the benefit for 20% of the effort  Diminishing returns for investment after that (other 80% of effort and only 20% gain)  Also known as Pareto Principle 18 small effort big gain