SOLID
S - Single Responsibility Principle
O - Open / Closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle
Single Responsibility Principle
An object has one reason to exist and one primary responsibility.
Open / Closed Principle
A class should be open for extension but closed for modification.
� You can add new features through inheritance.
Liskov Substitution Principle
You should be able to substitute a supertype with its subtype and have the program still function.
Interface Segregation Principle
Many specific interfaces are better than one general purpose interface (prevents God interface)
Dependency Inversion Principle
1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend on details. Details should depend on abstractions.
� If a higher-level component directly depends on a lower-level componen
DRY
Don't repeat yourself!
Every piece of knowledge must have a single, unambiguous, and authoritative representation
within a system.
YAGNI
You aren't gonna need it
KISS
Keep it simple, stupid!
Types of Code Smells:
-Bloaters
-Tool Abusers
-Change Preventers
-Dispensables
-Couplers
Bloaters
� Long Method
� Large Class
� Data Clumps
� Long Parameter List
� Primitive Obsession
� Comments
� Duplication, Combinatorial Explosion, Oddball Solution
Tool Abusers
� Switch Statements (Conditional Complexity)
� Refused Bequest
� Alternative Classes with Different Interfaces
� Temporary Field
The Change Preventers
� Divergent Change
� Shotgun Surgery
� Paralel Inheritance Hierarchies
The Dispensables
� Lazy Class
� Speculative Generality
� Data Class
� Duplicated Code
� Dead Code
� Solution Spraw
The Couplers
� Feature Envy
� Inappropriate Intimacy
� Message Chains
� Middle Man
� Indecent Exposure
Clean Code
� Meaningful names
� Functions (should be small, 20 lines or less)
� Comments (are lies waiting to happen)
� Formatting (be consistent and orderly)
� Error handling (Prefer exceptions to returning error codes)
Static Code Analysis
The process of analyzing source code without
actually running it
Design Pattern
A solution (general design anyone can apply) to a problem in a (reoccurring) context.
Design Principle
A basic tool/technique to help make your code more maintainable, flexible, or extensible.
Design Patterns
-Strategy
-Observer
-Command
-Template Method
-Iterator
-Singleton
-Abstract Factory
-Factory Method
-Decorator
-Adapter
-Facade
-Proxy
Behavioral Patterns
Are concerned with how classes and objects interact and distribute responsibility.
-Strategy
-Observer
-Command
-Template Method
-Iterator
Creational Patterns
Involve object instantiation and all provide a way to decouple a client from the objects it needs to instantiate.
-Singleton
-Abstract Factory
-Factory Method
Class Patterns
Describe how relationships between classes are defined via inheritance. Relationships
in class patterns are established at compile time.
-Adapter
-Factory Method
-Template Method
Object Patterns
Describe relationships between objects and are primarily defined by composition.
Relationships in object patterns are typically created at runtime and are more dynamic and flexible.
-Strategy
-Observer
-Command
-Iterator
-Singleton
-Abstract Factory
-Deco
Structural Patterns
Let you compose classes or objects into larger structures:
-Decorator
-Adapter
-Facade
-Proxy
Strategy Pattern
Defines a family of algorithms, encapsulates each one, and makes them interchangeable.
Strategy lets the algorithm vary independently from clients that use it.
Design Principles:
-Encapsulate what varies
Observer Pattern
Defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.
Design Principles:
-Encapsulate what varies.
-Program to interfaces, not implementations
-Favor compositi
Decorator Pattern
Attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
Design Principle: Open / Closed Principle
Factory Method Pattern
Defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a subclasses decide which concrete classes to create. Reduces
dependencies and increases flexibility.
Design Principles:
-Program to in
Abstract Factory Pattern
Allows a client to create families of objects without specifying their concrete classes.
Design Principles:
-Program to interfaces, not implementations.
-Open / Closed Principle.
-Encapsulate what varies.
-SOLID - Dependency Inversion Principle.
Factory Method vs. Abstract Factory
Factory Method
� Relies on inheritance
� Object creation is delegated to subclasses, which implement the abstract factory method to create objects.
� The intent
� Allow a class to defer instantiation to its subclasses.
Abstract Factory
� Relies on object
Singleton Pattern
Ensures a class has only one instance, and provides a global point of access to it.
-Dependency injection
Dependency injection
A technique where one object supplies the
dependencies of another object.
25-dollar term for a 5-cent concept.
� Dependency injection is simply providing the objects that an object needs (its dependencies) instead of having it construct them itself
Command Pattern
Encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations.
Benefits:
� Decouples the requestor of the action from the object that performs the action
Adapter Pattern
Converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
Applications:
� Interfacing with external APIs or any code that is prone to change.
Facade Pattern
Provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
-Law of Demeter
Applications:.
� Make a software library easier to use, understand, and test, since the fac
Law of Demeter
Design principle that promotes loose
coupling, also known as the Principle of Least Knowledge (talk only to your
immediate friends).
Guidelines
� Each unit should have only limited knowledge about other units:
only units "closely" related to the current u
Proxy Pattern
Provides a surrogate or placeholder for another object to control access to it.
Template Method Pattern
Defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Template Method lets subclasses decide how to implement steps in an algorithm without
changing the algorithm's structure.
-Hollywood Principle
The Hollywood Principle
Don't call us, we'll call you
Iterator Pattern
Provides a way to traverse a collection of objects without exposing its implementation.
Comparable Interface
Allows to compare arbitrary objects based
on their natural ordering.
a.compareTo(b) returns
� i < 0 if a < b
� i = 0 if a = b
� i > 0 if a > b
Comparator Interface
Allows to compare arbitrary objects based
on arbitrary ordering.
A comparator is an object that is external to the class of the objects it compares.
It provides a method compare(a,b) that returns
� i < 0 if a < b
� i = 0 if a = b
� i > 0 if a > b
OO in one sentence
Keep It DRY, Shy, and Tell the Other Guy
There are many aspects to writing good
code, but most of these hinge on a single underlying
quality:
flexibility
Shy code
Code shouldn't reveal too much of itself and shouldn't be too nosy into others affairs.
Static coupling
When a piece of code requires another piece of code to compile
Dynamic coupling
When a piece of code uses another piece of code at runtime.
Tell the other guy
Sending a message" to an object conveys an air of apathy. I've just sent you an order (or a request), and I don't really care who or what you are or (especially) how you do it. Just get it done. This service-oriented, operationcentric viewpoint is critic