Skip to content

BrianHuf/java-design-patterns

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

4 Commits
 
 
 
 
 
 

Repository files navigation

Java Design Patterns

Course work and notes from Design Patterns in Java by Dmitri Nesteruk. Generally follows the patterns established by the Gang of Four. Really great class!

SOLID

Collection of key design principles coined by Uncle Bob.

Single Responsibility Principle (SRP)

A class should have only one purpose to change

Open/Closed Principle (OCP)

A class should be open to extension, but closed to change. Once a class is in production, it should be complete and never change.

Liskov Substition Principle (LSP)

It should always be possible to replace a subclass with a parent class. Methods should still make sense.

Interface Segration Principle (ISP)

Avoid large interfaces. Don’t give API users more than they need.

Dependency Inversion Principle (DIP)

High level modules should not depend on low level modules. Both should depend on abstractions (interfaces).

Abstractions should not depend on details. Details should depend on abstractions.

Creational

Support creation of complex (likely immutable) objects with lots of fields by creating another Builder. Classic implementation StringBuilder.

Avoid using new. Use a Factory instead.

Builders often employ fluent interfaces. Using Java templates, inheritance can be used to keep code DRY (Don’t Repeat Yourself)

Create a copy of an object (often deep-copy). Don’t use Object.clone(). Deep copy can often implemented using Serialize

An object for which there is only one. Typically, a static getter is implemented. Lazy intitialization can be useful.

Structural

Using aggregation, create a component that looks like (adapts to) another interface

Connecting components with abstraction. Avoid cartesian product of classes by injecting an interface implementation

Extend an object using composition. Often, methods may be forwarded to decorated object

Provide a simple interface that wraps one or more complex objects. Argument defaulting may be applied.

Reduce memory by storing data patterns instead of repeated data (e.g. boolean array vs. ranges of settings).

Adjust behavior of underlying object. Similar to Decorator which is meant to extends. Proxy is meant to change behavior (e.g. add logging or caching).

Behavioral

A chain of references that are applied in order. The output of the previous may be passed to the next.

Instead of directly change stateful objects, create Command objects along with a CommandProcessor. This pattern provides a path to Undo and Redo

Use the same interface for singles and collections (e.g. Shape box and group)

Convert text into objects using a two step Lexer then Parser. Suggested to use a library for this (e.g. ANTLR).

A stateful object to help iterate on a collection. Implements next() and hasNext().

Funnel all communication throuh an object (e.g. a chatroom funnels all user communication - no direct communication).

A object used to rollback to a previous state. Related to Command.

A implementation of an interface which does the minimum possible. Used when the interface behavior is not desired.

An object (observer) that receives notifications/events from the observed and can act on it. Commonly used in MVC via the controller.

A mutable object that is changed with Triggers via a finite number of States. There’s often a map from current State to Trigger and next State. State can be an Enum or mapped to distint classes (classic Gang of Four example). Related to Finite State Machine. Suggested to use a library for this (e.g. Spring StateMachine).

Split an algorithm in high and low level parts. A high level implementation would accept an instance of the low level (Strategy) via composition. Similar in purpose to Template.

Split an algorithm in high and low level parts. Implement the high level as an abstract class. Extend high level class with low level implementations Similar in purpose to Strategy.

Separate behaviors from data by creating a Visitor object (behavior) which visits each data object’s accept method

About

Class notes from Udemy course

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages