Show Menu
Cheatography

OOP Midterm (CST8288) Cheat Sheet (DRAFT) by

OOP Midterm Prep. SOLID principles, UML and JDBC overview. DAO, Singleton, Factory, Builder, and Strategy design patterns.

This is a draft cheat sheet. It is a work in progress and is not finished yet.

Factory Design Patterns - Table

Feature
Simple
Factory
Abstract
Creation
Single factory class
Delegated to subclasses via polymo­rphism
Interface for families of related objects
Inheri­tance
None
Extends the factory class
Each concrete is a varient
Flexib­ility
Less flexible, modifi­cations needed
Highly flexible, follows Open/C­losed
Compat­ibility and consis­tency
Complexity
Simple
More complex, requires inheri­tance and polymo­rphism
Complex, involves multiple factories

Simple Factory Charac­ter­istics - Creational

Centra­lized Factory: Single method­/class creates all objects.
Simple Structure: Used for systems with limited number of object types.
e.g. Switch statement to run each constr­uctor.
Use when you have a small, fixed number of object types and won't need to extend.

Abstract Factory Elements - Creational

Abstract Factory (inter­face): Set of creation methods. Each for different abstract product.
Concrete Factory: Implements creation methods. Each CF corres­ponds to variant of product.
Abstract Product: Interface for set of distinct but related products.
Concrete Product: Implements abstract products, grouped by variant. Each abstract product (e.g. sofa/c­hair) must be implem­ented in all variants (e.g. Victor­ian­/Mo­dern).
Use when code needs to work with families of related products but don't want to depend on concrete classes.

Singleton - Creational

Only one class instance (e.g. db connec­tion, logs) created.
Race Condition: Two threads change same data at same time causes weird results.
Thread­-Safe: keyword Synchr­onized.
Double­-Ch­ecked Locking: check criteria before getting lock.
Disadv­antages: Global state, tight-­cou­pling (anti-­pat­tern).

Design Patterns

Solutions to common problems. Guideline, not strict.
Provides common vocab: helps collab­ora­tion.
Creational: Right objects created in right situat­ions. Instan­tiation optimi­zation.
Structural: How classe­s/o­bjects create larger struct­ures. System robustness.
Behavioral: Intera­cti­on/­com­mun­ication between objects. Efficient & flexible.

OOP Terms

Encaps­ulation: Data + methods.
Abstra­ction: Inform­ation hiding.
Inheri­tance: Sub/super classes.
Polymo­rphism: Treat all subs like super.

OOP Principles

Single Respon­sib­ility: One job = one reason to change.
Dependency Injection: Receive depend­encies from external source.

UML Use Case Diagrams

What a system does, not how.
Intera­ctions between actors and system.
Components: Actors, use cases (funct­ions), and relati­ons­hips.
Context: Clarif­ica­tions, constr­aints, except­ions, refere­nces, annota­tions.
 

Factory Method Elements - Creational

Creator (abstract): Declares factory method.
Concrete Creator: Implements factory method.
Product (inter­face): For objects created by factory method.
Concrete Product: Implements product interface.
Use when you need to create objects without specific class or expect product types to expand later.

Builder - Creational

Separated constr­uction from repres­ent­ation. Useful for objects that have many optional compon­ents. Allows method call chaining.
Builder Interface: Define methods for building.
Concrete Builders: Implement interface.
Director (optional): Order and use of build instru­ctions.
Product: Object that is constr­ucted.

DAO - Structural

From Core J2EE: separates busine­ss/­domain logic.
Primary Functions: Create, read, update, delete (CRUD).
Data Source: Connec­tion.
Domain­/Bu­siness Object:
Data Access Object: CRUD operat­ions. Abstracts access to DS.
Data Transfer Object: Models data (row). Follows Java Bean.
Java Bean Class: Default constr­actor, private vars with get/set. Implements Serial­izable.

Strategy - Behavioral

Defines family of algorithms (intent), puts each in separate class resulting in interc­han­geable objects.
Can switch between algorithms at runtime without altering code.
Promotes flexib­ility, extens­ibi­lity, and separation of concerns.
Strategy Interface: Defines set of behaviors all CS must implement.
Concrete Strategies: Implements SI. Each CS provides specific behavior (algor­ithm).
Context: Class that uses CS (delegates actual work). Contains reference to SI.

SOLID Principles

Purpose: To make software more unders­tan­dable, flexible, and mainta­inable.
Modular: Reduces bugs when creating new code.
Single Respon­sib­ility: Classes.
Open Closed: New features don't alter code.
Liskov Substi­tution: Sub substi­tutable for super.
Interface Substi­tution: Divide large interface into smaller.
Dependency Inversion: Depend on abstra­ctions, not concretes.

UML Sequence Diagrams

Intera­ction diagram. How objects interact in particular scenario over time.
Same diagrams from Web last term.