Domain-driven Design

1. Domain-driven Design • (book by Eric Evans) • Part of the system is a “domain model” • Customers and developers share “ubiquitous language”, which is expressed in domain model • You understand the problem best on the last day of the project, which is why the domain model keeps changing

2. Patterns • People don’t design from first principles. • People design by reusing ideas they have seen before • From previous projects • From books, courses, etc

3. What Really is an Object? • Relationship can be an object if it has attributes and relationships • Marriage has duration and children • Intersection has accidents • Attribute can be an object if it has attributes • Temperature is taken at a point in time

4. What Really is an Object? • Reservation -- a promise to give service to a customer • Ticket -- record the event of the customer paying for service in advance, • Flight -- an event in which an airplane provides service • Payment -- an event (transaction?) in which money is exchanged

5. Attributes are simpler than objects. • Associations are simpler than objects. • Models should be as simple as possible, but no simpler.

6. Why this is important • Many of the objects in a good design are NOT problem domain objects. • Example: ValueWithHistory • They can represent operations, processes, states, constraints, relationships, ...

7. Design for Reuse • Purpose is to make a system flexible, extensible, and easily changed. • Make things objects if they need to be changed and manipulated.

8. Design for Reuse • Goal is to build an application just by using preexisting objects. • Compose, don't program. • Relationship between objects as important as class hierarchy.

9. Refactoring

10. Piecemeal Growth • The way living things grow • The way software grows • More than just addition -- transformation

11. http://c2.com/cgi/wiki?ExtremeNormalForm • Your classes are small and your methods are small; you've said everything OnceAndOnlyOnce and you've removed the last piece of unnecessary code. • Somewhere far away an Aikido master stands in a quiet room. He is centered.. aware.. ready for anything. • Outside a sprinter shakes out her legs and settles into the block, waiting for the crack of the gun while a cool wind arches across the track. • Softly, a bell sounds.. all of your tests have passed. • Your code is in ExtremeNormalForm.. tuned to today and poised to strike at tomorrow.

12. Extreme Normal Form Defined • All the code is tested. The code passes all the tests. • No one on the team can think of code in the system that they could remove or simplify without reducing the feature set. • You never have to go more than one place to change one thing.

13. Refactoring • Extreme Normal Form is a result of refactoring • Refactoring: changes to the organization of a program, not its function. • Behavior preserving program transformations.

14. Why refactoring is important • Only defense against software decay. • Often needed to fix reusability bugs. • Lets you add patterns after you have written a program; lets you transform program into framework. • Lets you worry about generality tomorrow; just get it working today. • Necessary for beautiful software.

15. Refactoring • Refactoring: Improving the Design of Existing Code by Martin Fowler with contributions by Kent Beck, John Brant, William Opdyke, and Don Roberts, Addison-Wesley 1999 • www.refactoring.com

16. How to refactor • Make changes as small as possible. • Test after each change. • Many small changes are easier than one big change. • Each change makes it easier to see that more changes are needed.

17. How to Refactor • Use Sunit to write test suite • Use TestRunner to run it; “keep your light green”. • Plan change so it is a series of small refactoring. • Run tests after every refactoring, once every 5 minutes.

18. Example: Strategy • Initially: class C with public method m • 1) Make a Strategy class S with empty method mFor: • 2) Add instance variable “strategy” to C, initialize it with an instance of S, and change m to have “strategy mFor: self” • 3) Move code from m to mFor: • 4) Move private methods from C to S.

19. Refactoring browser • A better browser • Automates many refactorings - renaming, moving code, splitting • Undo • Lint helps you find places that need to be refactored.

20. Code Smells • Data class • Switch statements • Speculative generality • Temporary field • Refused bequest Duplicated code Long method Large class Long parameter list Message chain Feature envy

21. Duplicate code • Eliminate duplication by • making new methods • making new objects • moving methods to common superclass

22. Long methods • Each method should do one thing. • One comment for each method. • Method should fit on the screen. • Method is all on same level of abstraction. • Method should be in right class.

23. FileSystemHandler • directoryResponse: aDirectory • self indexFileNames • do: [:each | indexFile | • indexFile := aDirectory construct: each. indexFile safeIsReadable • ifTrue: [^FileResponse fileNamed: indexFile]]. • ^DirectoryResponse fileNamed: aDirectory in: self • indexFileNames • ^#('index.html' 'index.htm' 'default.html' 'default.htm')

24. FileSystemHandler • directoryResponse: aDirectory • (self indexFilesFor: aDirectory) • do: [:indexFile | indexFile safeIsReadable • ifTrue: [^FileResponse fileNamed: indexFile]]. • ^DirectoryResponse fileNamed: aDirectory in: self • indexFilesFor: aDirectory • ^#('index.html' 'index.htm' 'default.html' 'default.htm') • collect: [:each | aDirectory construct: each]

25. Long method in CompositeWiki • responseKeyFor: aRequest • | mightNotBeTheRightPlace key | • mightNotBeTheRightPlace := aRequest identifier size >= self depth. • mightNotBeTheRightPlace • ifTrue: [key := aRequest identifier at: self depth] • ifFalse: • [^aRequest postDataAt: #COMMAND • ifAbsent: [aRequest postDataAt: #DEFAULT_COMMAND ifAbsent: [self rootKey]]]. • (self containsAction: key) • ifTrue: [aRequest decodeUrlencodedFormData: aRequest lastIdentifier]. • ^key

26. Method in CompositeWiki • responseKeyFor: aRequest • aRequest identifier size < self depth • ifTrue: • [^aRequest postDataAt: #COMMAND ifAbsent: • [aRequest postDataAt: #DEFAULT_COMMAND ifAbsent: • [self rootKey]]]. • (self containsAction: (self keyIn: aRequest)) • ifTrue: [aRequest decodeUrlencodedFormData: aRequest lastIdentifier]. • ^self keyIn: aRequest

27. responseKeyFor: aRequest • (aRequest isKeyMissingFor: self) • ifTrue: • [^aRequest postDataAt: #COMMAND ifAbsent: • [aRequest postDataAt: #DEFAULT_COMMAND ifAbsent: • [self rootKey]]]. • (self containsAction: (self keyIn: aRequest)) • ifTrue: [aRequest decodeUrlencodedFormData: aRequest lastIdentifier]. • ^self keyIn: aRequest

28. Data class • Some classes have only variables and accessors. • Look for places where accessors are used and eliminate “feature envy” and “message chains”.

29. Feature Envy • teacher classes add: thisClass. • teacher classLoad: (teacher classLoad + 1) • teacher addClass: thisClass

30. Message chain • Eliminate navigation code • Ensures that user of an object doesn’t have to know many classes • aFigure boundingBox center

31. Message chain • Law of Demeter: • Method should only send messages to classes of instance variables and arguments. • anX m1 m2 m3 m4 m5 m6 => anX m6

32. Large classes • More than seven or eight variables • More than fifty methods • You probably need to break up the class • Components (Strategy, Composite, Decorator) • Inheritance

33. Long parameter lists • If you see the same set of parameters repeated in several methods, bundle them into a new object. Create accessers to get the original parameters from the object. Change the methods to use the new object instead of the parameters. • Then figure out what other functionality needs to move to the object.

34. Case Statements • Use polymorphism, not case statement. • Make class hierarchy, one class for each case. • Make a method for each case statement. • Make each branch of case statement be a method in a class

35. Refused bequest • Subclass does not use all the inherited methods. • Overrides methods with different algorithm • Overrides methods with error message • Solution: • Make a new superclass

36. Refused Bequest A doX doY C doY B doX B doX A doX

37. Temporary field • Instance variable is only used during part of the lifetime of an object. • For example, it is only used while the object is initialized. • Move variable into another object

38. Non-localized plan • Adding a feature requires a plan. If adding a feature requires changing many parts of a program, it is called a “non-localized plan”. • Parallel class hierarchies: adding a class in one class hierarchy requires adding a class in another • Example: a new view class requires a new controller class

39. How to refactor non-localized plan • Make a new object that represents everything that changes. • Methods that change together should stay together.

40. When to refactor • If a new feature seems hard to implement, refactor. • If a new feature created some ugly code, refactor. • When you can’t stand to look at your code, refactor.