Software Development: Beyond Training wheels
Download as PPTX, PDF1 like467 views
The document discusses various programming concepts and design approaches, including static classes, object-oriented programming, currying, data-driven design, and responsibility-driven design. It explores the differences between transaction scripts, anemic domain models, and rich domain models, emphasizing the importance of encapsulation and the role of domain objects in managing business logic. Key takeaways highlight the superiority of a robust domain model over simple data models and the significance of service layers in coordinating functionality.
![Currying (continued)
• add x y = x + y
• map (add 2) [1, 2, 3] -- gives [3, 4, 5]
• add2 y = add 2 y
• map add2 [1, 2, 3]](https://image.slidesharecdn.com/trainingwheels-161118020032/85/Software-Development-Beyond-Training-wheels-6-320.jpg)
![Stack in procedural style
structure stack:
maxsize : integer
top : integer
items : array of item
procedure push(stk : stack, x : item):
if stk.top = stk.maxsize:
report overflow error
else:
stk.items[stk.top] ← x
stk.top ← stk.top + 1
procedure pop(stk : stack):
if stk.top = 0:
report underflow error
else:
stk.top ← stk.top − 1
r ← stk.items[stk.top]](https://image.slidesharecdn.com/trainingwheels-161118020032/85/Software-Development-Beyond-Training-wheels-13-320.jpg)
Software Development: Beyond Training wheels
- 3. Training Wheels • Programming with Static Classes • Data Driven Design • Transaction scripts • Anemic Domain Model
- 4. Complexity vs Familiarity • lineItemList.stream().map(lineItem -> lineItem.getTerms().getPrice()).reduce(ZERO, BigDecimal::add) • map() • reduce() • anonymous function • Is this code complex or is the programming style unfamiliar?
- 5. currying • function add (a, b) { return a + b; } • function add (a) { return function (b) { return a + b; } } • add(3)(4); • var add3 = add(3); • add3(4); • https://en.wikipedia.org/wiki/Currying
- 6. Currying (continued) • add x y = x + y • map (add 2) [1, 2, 3] -- gives [3, 4, 5] • add2 y = add 2 y • map add2 [1, 2, 3]
- 8. Static classes • public class Position{ • public double latitude; public double longitude; } • public class PositionUtility { • public static double distance( Position position1, Position position2 ) public static double heading( Position position1, Position position2 ) } • Positions are parameters to PositionUtility
- 9. Static classes(..continued) • double distance = PositionUtility.distance( myHouse, coffeeShop ); double heading = PositionUtility.heading( myHouse, coffeeShop);
- 10. Object Oriented Programming • public class Position { • public double distance( Position position )} • public double heading( Position position ) {} • private double latitude; private double longitude; }
- 11. Object Oriented Programming(..continued) • Position myHouse = new Position( , ); • Position coffeeShop = new Position( , ); • double distance = myHouse.distance( coffeeShop ); • double heading = myHouse.heading( coffeeShop );
- 12. Currying vs Object Orientedness • add(3, 4) => PositionUtil.distance(Position position1, Position position2 ) • add 3 = > Position house = new …. • add3(4) = > house.distance(coffeeShop) • ‘identity’
- 13. Stack in procedural style structure stack: maxsize : integer top : integer items : array of item procedure push(stk : stack, x : item): if stk.top = stk.maxsize: report overflow error else: stk.items[stk.top] ← x stk.top ← stk.top + 1 procedure pop(stk : stack): if stk.top = 0: report underflow error else: stk.top ← stk.top − 1 r ← stk.items[stk.top]
- 14. Stack in Object Oriented style public Class Stack { private ... public Stack(){} public push(){} public pop(){} }
- 15. Encapsulation and Information Hiding • Changes to fields(from array to linked list), will cascade to other methods • Lazy initialization in the constructor, will move additional behavior to push and pop
- 16. capsule • a small (glass or plastic) container that has something (such as a liquid) inside of it. • There is an inside and outside to the capsule • There is no or partial understanding of the contents of the capsule for the outside
- 17. Invariants • size of the stack = total valid pushs – total valid pops • stk.top is at the top of the data in the stack • The responsibility of maintaining these invariants lie with Stack • Stack is in charge of its destiny • Single place to reason
- 18. encapsulation • encapsulate what varies • encapsulating with classes frees a dimension of change • Object oriented-ness provides currying at the object level
- 21. Different schools • Data Driven Design: Head, Tail, Body, 4 Legs • Event Driven Design: Start, Stop, Speed Up, Slow Down • Responsibility Driven Design: eat, run, stand, sit, sleep, poop
- 22. Data driven design • Modelling done for Data(ER diagrams, DFDs) • Programs are massagers, routers and processors of data • No recommendations on modularizing the behavior • Typically this behavior is placed in classes Service, Util, Helper or Manager. • Useful for building CRUDy applications • https://en.wikipedia.org/wiki/Data-driven_programming
- 23. Responsibility Driven Design focuses on the contract by asking: • What actions is this object responsible for? • What information does this object share?
- 24. RDD:Objects • things that have machine like behaviors that can be plugged together to work in concert • play well-defined roles and encapsulate scripted responses and information • Subsystem: logical grouping of collaborators.
- 25. RDD:responsibilities • an obligation to perform a task or know information • public(checkout), private, subordinate(provider), sequencing
- 26. Data Driven vs Responsibility Driven Design • https://practicingruby.com/articles/responsibility-centric-vs-data- centric-design
- 27. Control Style • distribution of control responsibilities that results in developing a control style. • Central • Clustered • Delegated • https://en.wikipedia.org/wiki/Responsibility-driven_design • Same school of thought as Kent Beck and Ward Cunningham(http://wiki.c2.com/?ResponsibilityDrivenDesign)
- 29. Transaction Scripts • business applications modelled as a series of transactions. • Each transaction will have its own Transaction Script • A Transaction Script organizes all this logic primarily as a single procedure • although common subtasks can be broken into sub procedures. • Not (functionally)scalable
- 30. Transaction Scripts: Symptoms • AddHandler • RemoveHandler • ViewHandler • PaymentHandler
- 36. Fowler Speak: Anemic Domain Model • Domain objects are just bags of getters and setters • No behavior in Domain objects • a set of service objects which capture all the domain logic. • Services use domain model for data • http://www.martinfowler.com/bliki/AnemicDomainModel.html
- 37. invariants • Remember the stack example, similarly maintaining invariant • The responsibility of getting the terms lies with Checkout and not an external utility/Service
- 39. Application Services (..continued) • This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks • delegates work to collaborations of domain objects in the next layer down. • The key point here is that the Service Layer is thin - all the key logic lies in the domain layer. • Domain objects are re-used, services are typically not
- 40. Application Services (..continued) • In general, the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model. • If all your logic is in services, you've robbed yourself blind.
- 41. Rich Domain Model • https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich- domain-models/ • Services in a service-oriented architecture are usually application services that encapsulate use cases. • The only difference to plain transaction scripts is often that they use parameter objects that are named after domain objects.
- 42. Static Object Data Driven Responsibility Driven Transaction Script Domain Model Anemic Domain Model Rich Domain Model Procedural
- 43. Static Object Data Driven Responsibility Driven Transaction Script Domain Model Anemic Domain Model Rich Domain Model Domain Driven Design Naked Objects
- 44. Domain Driven Design • https://en.wikipedia.org/wiki/Domain-driven_design • Entity • Value Object An object that contains attributes but has no conceptual identity. They should be treated as immutable. • Service • Factory.
- 45. Entity • An object that is not defined by its attributes, but rather by a thread of continuity and its identity. • have life cycles that can radically change their form and content • class definitions, responsibilities, attributes, and associations should revolve around who they are • Eg. Cart, Checkout, Order, Store
- 46. Services • The operation relates to a domain concept that is not a natural part of an Entity or Value Object • The interface is defined in terms of other elements in the domain model • The operation is stateless
- 47. Services (..continued) • They exist in three layers • Application • Domain • Infrastructure • http://tinyurl.com/z2yeutt
- 48. Application Services • Application Services are the interface used by the outside world, where the outside world can’t communicate via our Entity objects, but may have other representations of them. • Application Services could map outside messages to internal operations and processes • communicating with services in the Domain and Infrastructure layers to provide cohesive operations for outside clients. • Don’t contain any business logic • Not part of domain layer
- 49. Domain services • Domain services are the coordinators, allowing higher level functionality between many different smaller parts. • Part of domain model • Can contain business logic
- 50. Factories and Repositories • http://tinyurl.com/jdhuebj • Factory encapsulates the knowledge needed to create a complex object • Can use FactoryMethod, AbstractFactory or Builder • Can create Entities and ValueObjects
- 51. Repositories • To do anything with an object, you have to hold a reference to it. How do you get that reference? • One way is to create the object • A second way is to traverse an association. You start with an object you already know and ask it for an associated object. • Repositories are the second way • Example: StoreRegistry
- 53. Take Aways • Domain Model >> Data Model • Domain Objects >> bags of getters and setters • Heart and Brain of your system is Domain Model • Domain Objects(and services) are responsible for all of our business logic • Entities have identity and continuity • Entities trump Services • Layers preceding Domain Model have as little logic as possible • Domain Objects react to ’business events’ and delegate