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
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
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