Learn about the solid principles of design along with some additional useful principles and practices and also few important considerations to avoid in your design. Introduction is also provided to the Design Patterns. This is usually taken as a hands on session with design and refactoring exercises.

1. SOLID PRINCIPLES OF
DESIGN
Principles and practices that power the patterns
(Design Series 01)
Presenter: Heartin Jacob Kanikathottu

2. TOPICS
• Review of important prerequisites: OOPs concepts and UML
• The SOLID principles of design
• Additional principles and practices
• What to avoid in your design
• Problem solving time
• Intro to Design Patterns
• Resources and references

3. OOPS CONCEPTS
• Encapsulation
• Wrapping up of data (properties) and behavior (methods) of an object into a single unit.
• Data hiding - hiding irrelevant information from the users of a class.
• Inheritance
• Describes the parent child relationship between two classes.
• Polymorphism
• Ability to change form.
• Abstraction
• Capture only those details that are relevant to the current level.

4. UNIFIED MODELLING LANGUAGE (UML)
• A picture can speak thousand words.
• UML diagrams are those pictures which can speak all those words about your design.
• May be classified as static and dynamic
• Static diagrams include class, object, and use case diagram. Implementation model
diagrams, which are a subset of static diagrams include component, deployment, and
package diagram.
• Dynamic diagrams include sequence diagram, communication, state and activity
diagram.
• Drawing diagrams is the best way to learn about patterns and principles.
• Keep drawing as much as possible

5. THE SOLID PRINCIPLES OF DESIGN
• Single responsibility principle (SRP)
• Every class should have a single responsibility.
• Open Close Principle (OCP)
• Open for extension, closed for modification.
• Liskov substitution principle
• Objects should be replaceable with instances of subtypes without altering correctness.
• Interface segregation principle
• Many client-specific interfaces are better than one general-purpose interface
• Dependency inversion principle (DIP)

6. ADDITIONAL PRINCIPLES AND PRACTICES
• Program to interfaces
• Don’t repeat yourself (DRY)
• Low coupling
• Encapsulate what varies (EWV)
• Prefer composition over inheritance
• Keep it simple, stupid (KISS)
• Unit Testable code
Note: For more explanations and the latest updated list of additional principles and practices,
please refer to http://codingarchitect.com/additional-design-principles-and-best-practices

7. WHAT TO AVOID IN YOUR DESIGN?
• Run-Time Type Identification (RTTI)
• Cyclomatic complexity (CC)
• Swiss knife syndrome
• Lookup
• Bidirectional coupling and cyclic coupling
• God class
• Downcast
Note: For more explanations and the latest updated list of what to avoid in design, please refer
to http://codingarchitect.com/things-to-avoid-in-your-object-oriented-design

8. PROBLEM SOLVING
• Duck Simulation App
• Design a Duck Simulation App initially with two specific ducks that has two common
operations quack() and swim(), and a specific operation of display().
• Add a rubber duck, that will quack differently (squeak), but assume it can still swim and
of course display will be different.
• Add a fly method for the Ducks. Note that rubber ducks won’t fly.
• Add a Robo duck to the design, which whose quack, fly and display will be different,
assuming it will also swim like a duck.
• Finally refactor the code by encapsulating what varies.
Note: Please refer to and refactor the provided code samples during the session, however this is
not a requirement. You can also design using pen and paper, which is sometimes more
preferred.

9. ADDITIONAL PROBLEM SOLVING
• STOP WATCH DESIGN
• Design a stop watch API that will allow you to change states only to the allowed ones.
• Start by designing the states and implement it in a procedural way.
• Refactor code to avoid cyclomatic complexity (if, else or switch) as much as possible and
try to keep the logic of state transition within each state.
• THREAD SYNCHRONIZATION
• Applying patterns in real problems.
• Design three threads that will be executed one after other in same order, and in a cycle.
• Make use of the Design Pattern you used in the Stop Watch Design example.
Note: Please refer to and refactor the provided code samples during the session, however this is
not a requirement. You can also design using pen and paper, which is sometimes more
preferred.

10. QUICK INTRO TO DESIGN PATTERNS
• General reusable solution to a commonly occurring software design problem.
• Benefits of Design Patterns
• More productive, solving design problems faster.
• Shared vocabulary.
• Documented with its name, type, intent, use, examples, structure, related patterns,
consequences, and even implementation details.
• Patterns are based on principles
• Better understanding of principles will help understand the design patterns better.

11. QUICK INTRO TO DESIGN PATTERNS
(COND..)
• Gained popularity after book published by the Gang Of Four: Erich Gamma,
Richard Helm, Ralph Johnson, and John Vlissides.
• GOF design patterns can be classified into three categories:
• Creational
• Structural
• Behavioral
• Many other patterns
• Java EE Patterns, EAI Patterns, Concurrency Patterns etc.

12. RESOURCES & REFERENCES
• Head First Design Patterns By Eric Freeman, Elisabeth Freeman, Bert Bates,
Kathy Sierra
• www.JavaJee.com and www.CodingArchitect.com
• http://javajee.com/summary-of-object-oriented-programming-oop-concepts-in-java
• http://codingarchitect.com/important-uml-diagrams-required-to-work-with-object-
oriented-design-patterns
• http://codingarchitect.com/book/object-oriented-design-patterns-and-principles
Note: www.JavaJee.com and www.CodingArchitect.com are my personal blogs. Please refer to the above
links, for further references and resource links. Please feel free to contact me for any queries or doubts.