- A pattern is a solution to a problem in a context
- It’s a balance btw objective and constraints
Good Practices
EPP-BOD-PHS
Encapsulate what varies
- Identify the aspects of the application that vary and separate them
- Basis for almost every design pattern
Prefer interfaces, not concrete classes
- Provides higher level of decoupling
- Allows for Polymorphism
Prefer Has-A over Is-A
- Favour composition over Inheritance
- Change behaviour at runtime
Build loosely coupled systems
- Minimize inter-dependency btw objects
- Flexible and scalable OO systems
Open-closed principle
- Classes should be open for extension and closed for modification
- If requirements change extend the class don’t modify it
Dependency Inversion principle
- Depend upon abstractions not concrete classes
- High level components should not be dependent on low level objects but rather on abstraction
Principle of Least Knowledge
- Reduce interactions btw objects to very few close classes
- Prevent designs in which a large number of classes are coupled together
- From an object method invoke only,
- Object itself
- Any component of the object
- Objects passed in as parameter to the method
- Objects created by the method
The Hollywood Principle
- Don’t call us we will call you
- High level components decide when and how low level components are needed
- Similar to dependency inversion
- Prevents dependency rot
Single Responsibility
- A class should have only one responsibility
- High cohesion
- Class methods should all be involved in one area of change
Hollywood principle vs Dependency Inversion
- Both achieve decoupling
- Dependency inversion - avoid concrete classes, use abstractions instead
- Hollywood principle - low level components are not dependent on high level components
SOLID
Single Responsibility - A class should have only a single responsibility
Open/ Closed Principle - A class should be open for extension and closed for modification
Liskov Substitution - Objects should be replaceable with instances of their sub types without altering program correctness
Interface Segregation - Client should not be forced to depend on interfaces that they don’t use
Dependency Inversion - Program to an interface not to an implementation
Advantages of Design Patterns
- Communicates best practice in standards
- Helps with DRY
- Reduced development time and cost
A pattern language, a term coined by architect Christopher Alexander is a structured method of describing good design practices within a field of expertise
Categories of Design Patterns
Creational Patterns - Provide object creation mechanisms that increase flexibility and reuse of existing code
Structural patterns - Explains how to assemble objects and classes into larger structures, while keeping these structures flexible and efficient
- Facilitates inter object communication when one object is not accessible to the other due to it’s incompatible interface
- Deals with object delegating responsibility to other objects
Behavioural patterns - takes care of effective communication and assignment of responsibilities btw objects
Essential elements of a pattern
- Pattern name - identifier
- Problem - when to apply a pattern
- Solution - template of the design solution
- Consequences - results ans consequences
Creational Patterns
Structural Patterns
| Structural Class pattern | Structural Object patters |
|---|---|
| Uses inheritance to combine interfaces of multiple classes | Uses object composition to combine interfaces of objects into one unified interface |
| Relatively rare | Relatively common |
Behavioural Patterns
- Template method
- Mediator
- Chain of responsibility
- Observer
- Strategy
- Command
- State
- Visitor
- Iterator
- Interpreter
- Memento
Measure software size
- LoC - Lines of Code
- Deployment size
Why software Architecture
- Flexible foundation for evolution
- Easier maintenance
- Manage complexity through abstraction
UML
- Unified Modeling Language
- A standard for modeling OO software
UML Class diagrams
- Class name is the only mandatory field
- 3 row arrangement (class name, attributes, methods)
- Attributes =>
<access_specifier> <attribute_name> : <datatype> - Under attributes,
/- derived parameter (not an actual)+- public#- protected-- private- Static attributes are to be underlined
- Under methods,
- Use the function signature
- You can add an optional fourth row
Responsibilitiesthat talks about what the class is responsible for - If the class name is in italics then it’s an abstract class
Relationships
kinds,
- dependencies
- generalizations
- associations
Dependency relationships
- Indicates a semantic relationship btw two classes
Generalization
- Connects a sub class to it’s super class
- Reverse is called specialization
Note
JAVA doesn’t support multiple inheritance (i.e, one subclass from multiple super classes)
Association
- A communication link btw two classes
We can name the association
We can use dual association,
We can define navigatability,
Association can be objects themselves (association or link classes)
A class can have self association,
We can model aggregation
- indicates a whole-part relationship
- Denoted by a hallow diamond
We can model composition
- Indicates strong ownership
- The lifetime of the part is coincident with the lifetime of the whole
- Denoted by a filled diamond
Interface
- An interface is a named set of ops that specify the behavior of objects without revealing their inner structure
- Indicated by
<<interface>> - Interfaces do not get instantiated
- They do not have data attributes
Interface realization relationship,
Anti-patterns
- Design
- Programming to concrete classes rather than abstractions
- Coupling logic like logging and security in code - Aspect Oriented Programming (AOP) can be used to prevent this
- Development
- Golden Hammer - Obsessive use of a known technology or pattern over what’s more relevant
- Input Kludge
- Software that mishandles simple user inputs is an input kludge
- Use a monkey test to detect input kludges
- Architecture
- Reinvent the wheel
- Vendor lock in