1. Software Design Fundamentals
Ajay Shrivastava
1

2. Design Fundamentals:
• Buzzwords :
– Extensibility
– Maintainability
– Modularity
• Layman Terms: Think of Future:
– Addition of behaviors/types.
– Modification of behaviors/types.
– Deletion/Disabling of behaviors/types.
2

3. Duck Game: Design Exercise
3

4. Duck Game: Its Easy!!
Switch .. case :
------------------------------------------------------
Enum DuckType
{
RedHeadDuck;
MallardDuck;
}
Quack(int ducktype)
{
switch(ducktype)
{
case :RedHeadDuck:
RedHeadQuack();
case : MallardDuck :
MallardQuack();
case XYZ :
------
default:
------
}
If .. Else .. If ladder :
------------------------------------------------------
Enum DuckType
{
RedHeadDuck;
MallardDuck;
}
Quack(int duckType)
{
if(duckType == RedHeadDuck)
{
RedHeadQuack();
}
else if(duckType == MallardDuck)
{
MallardQuack();
}
else if ()
--
else
--
}

5. Duck Game: Now Think of future …
• Add a common default behavior to all ducks:
• Need to create the new function with all cases
• Might miss out some kind of ducks.
• Add a new Duck Type:
• All functions must be remembered and updated too.
5

6. Duck Game: Solution: OO design
6

7. Duck Game: Future: New requirement
• Flying ducks :
7

8. Duck Game: That’s Easy!
8

9. Duck Game: Solution 2:
9

10. Duck Game: Think of future: Rubber ducks ..
A localized update to the code caused a non local side effect (flying rubber ducks)!
10

11. Duck Game: What’s wrong ..
11

12. Duck Game: Solution 3:
12

13. Duck Game: Think of future: Wooden ducks ..
• Need to override these methods in many classes
• Otherwise they start Quacking & flying by default 
13

14. Duck Game: Solution 4: Interfaces:
• Take fly() out of Duck superclass and make a Flyable interface with a fly() method.
• All ducks that’s want to fly will implement the Flyable interface and have a fly() method.
• Similarly have a Quackable interface also.
14

15. Duck Game: Solution 4: Problem ..
• If having to overrride a few methods was BAD!
• How are you going to feel when you need to make a little change to the flying behavior
• In all 48 of flying Duck subclasses!!
15

16. Duck Game: Crux of the problem..
16

17. Duck Game: Solution 5
17

18. Duck Game: Solution 5 contd..
18

19. Duck Game: Solution 5 contd..
19

20. Duck Game: Solution 5: Full design..
20

21. Duck Game: Code …
Code after Design:
------------------------------------------------------
• Duck duck = new RedHeadDuck();
Perform(duck);
• Perform(Duck duck)
{
duck->Display();
duck -> Quack();
duck->Swim()
duck->Fly()
}
If .. Else .. If ladder :
------------------------------------------------------
• int _currentDuckType = ReadHeadDuck;
Perform(_currentDuckType )
• Perform(int duckType)
{
Display(duckType);
Quack(duckType);
Swim(duckType);
Fly(duckType);
}
21
• Quack(int duckType)
{
if(duckType == RedHeadDuck)
{
RedHeadQuack();
}
else if(duckType == MallardDuck)
{
MallardQuack();
}
else if ()
--
else
--
}
• Class RedHeadDuck: public Duck
{
Display();
Swim() { }
Fly() ( flyBehavior->Fly(); )
Quack() { quackBehavior-> Quack(); }
FlyBehavior flyBehavior;
QuackBehavior- quackBehavior;
}
• Class RedHeadDuck: public Duck
{
Display() { // display of RedHead }
}

22. Duck Game:
22

23. Post Mortem:
• What caused design changes :
– Layman :
• Addition
• Modification
• Deletion [Not covered in this exercise].
– Buzzwords : Problems were in:
• Extensibility
• Maintainability
• Modularity.
23

24. Design: Impact… [ where’s money  ]
• Effects :
– Extensibility:
• Less cost in adding new features.
– Maintainability:
• Less cost in modifying/removing behavior, fixing bugs.
– Modularity:
• is part of maintainability.
• Side Effects:
– Generic(Reusable) code => Less Code.
– Less Code => Less Bugs !!!
– Less Code => Smaller files (binaries, Javascript etc).
– Smaller files => Better Performance (small memory footprint, less time to load)
– Better performance => Simplest & Most Effective Magic!!
24

25. Design: Recommendations..
• Many functions having same/similar ifs/switch, is an indication for Need
for Design.
– Otherwise Addition/Modification/Deletion is costly and prone to bugs (even for the type
which you don’t want to touch).
– Try to at least get to first OO design in this deck.
• Never intermix CRM logic with any non CRM Components logic.
– It becomes difficult to remove/replace it or support another parallel similar component.
– Vancouver ?? Sharepoint?? Dundas??
• Functions should NOT be more than a screen/page long.
– Automatically enforces modularity.
– Should be tracked in review.
25

26. Questions ??
26

27. Thank You!
27