The document covers the solid principles of design, including key object-oriented programming concepts and design patterns that enhance software development. It emphasizes the importance of principles like single responsibility and open-closed principles, along with additional practices and common pitfalls to avoid. Additionally, it includes practical problem-solving exercises and resources for further learning about design patterns.

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.