software development practices like procedural coding are like training wheels, they help when we start development, but are detrimental later. This presentation lists few such practices and their alternatives

1. Software Development
Training wheels
Naveen Muguda

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

19. Spring2.0 feature
• http://tinyurl.com/j7wykok

20. Design Approaches

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

32. Domain Model
• https://www.cp.eng.chula.ac.th/~wiwat/EAA/EAAdomain.pdf

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

38. (Application)Services

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

52. Naked Objects
• https://en.wikipedia.org/wiki/Naked_objects

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