Showing posts with label Enterprise Patterns. Show all posts

Saturday, 24 August 2013

Design patterns - catalog

🚀 Master Design Patterns & Software Architecture!

Subscribe to Ram N Java for clean, visual, and beginner-friendly programming tutorials!

What is the Design Patterns Catalog?

Design patterns represent proven, standardized solutions to common software design problems encountered in real-world application engineering. A Design Patterns Catalog organizes these recurring architectural patterns into logical categories, enabling engineers to select the exact right blueprint for any development challenge.

In modern Java and enterprise systems, there are over 50+ design patterns spanning basic object creation to distributed enterprise architectures.

The Complete Categories in the Design Patterns Catalog

Here is the overarching breakdown of design pattern classifications used across modern software engineering:

Creational Design Patterns: Focus on class instantiation and object creation mechanisms (e.g., Singleton, Factory Method, Abstract Factory, Builder, Prototype, Object Pool).
Structural Design Patterns: Focus on class and object composition to assemble larger, flexible structures (e.g., Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy).
Behavioral Design Patterns: Deal with communication, algorithms, and assigning responsibilities between collaborating objects (e.g., Strategy, Observer, Command, Iterator, State, Template Method).
J2EE / Java EE Patterns: Enterprise patterns for building multi-tier web applications (e.g., Front Controller, Intercepting Filter, View Helper, Composite View).
Domain Logic Patterns: Organize business logic cleanly (e.g., Transaction Script, Domain Model, Table Module).
Data Source Architectural Patterns: Connect business logic to persistent data stores (e.g., Table Data Gateway, Row Data Gateway, Active Record, Data Mapper).
Object-Relational Behavioral Patterns: Manage how in-memory objects interact with relational databases (e.g., Unit of Work, Identity Map, Lazy Load).
Object-Relational Structural Patterns: Map complex object hierarchies to relational database tables (e.g., Identity Field, Foreign Key Mapping, Association Table Mapping).
Object-Relational Metadata Mapping Patterns: Automate data mapping using metadata schemas (e.g., Metadata Mapping, Query Object, Repository).
Web Presentation Patterns: Structure web user interfaces and request lifecycles (e.g., Model-View-Controller, Page Controller, Application Controller).
Distribution Patterns: Handle remote communication across distributed network boundaries (e.g., Remote Facade, Data Transfer Object).
Offline Concurrency Patterns: Handle multi-request business transactions safely (e.g., Optimistic Offline Lock, Pessimistic Offline Lock, Coarse-Grained Lock, Implicit Lock).
Session State Patterns: Manage user sessions across stateless web servers (e.g., Client Session State, Server Session State, Database Session State).
Base Patterns: Fundamental building blocks supporting complex patterns (e.g., Gateway, Mapper, Layer Supertype, Separated Interface, Registry, Value Object).
Concurrency Patterns: Manage multithreading, thread safety, and resource scheduling (e.g., Thread Pool, Read-Write Lock, Monitor, Lock, Scheduler).

Why Study the Design Pattern Catalog?

Standard Vocabulary: Gives developers and architects a shared language to communicate system architectures cleanly.
Prevents Code Duplication & Smells: Replaces ad-hoc workarounds with time-tested, battle-proven design strategies.
Foundation of Enterprise Frameworks: Frameworks like Spring, Hibernate, Java Concurrency, and Java EE are built directly on top of these catalogs.

Thursday, 15 August 2013

Template View Design Pattern

Master Enterprise Design Patterns!

Subscribe to Ram N Java for clean software architecture explanations, web patterns, and enterprise Java tutorials!

🔔 Subscribe to Ram N Java

What is the Template View Design Pattern?

The Template View Design Pattern is an enterprise presentation-tier design pattern (frequently referenced in Martin Fowler's Patterns of Enterprise Application Architecture). It provides a structured way to render dynamic HTML content by embedding server-side program markers or scripts directly within static visual templates.

Rather than writing code that generates entire HTML documents using string concatenations or print statements, developers write standard HTML pages and insert specialized placeholders or script tags where dynamic model data should be rendered.

How the Template View Pattern Works

The main philosophy behind Template View is separation of visual presentation from complex business logic:

Static Page Framework: Designers create standard HTML layout pages (headers, navigation bars, CSS styling, and footers) using regular web tools.
Dynamic Placeholders: Specific tags or expressions (such as JSP expressions, Thymeleaf tags, or ASP tags) pull data passed from the controller or model.
Server-Side Processing: During request execution, the template engine processes the page, replaces markers with real database or business object values, and returns standard HTML to the browser.

Key Benefits & Real-World Implementations

Common implementations of this pattern include JavaServer Pages (JSP), Thymeleaf, FreeMarker, and Velocity. Major advantages include:

Improved Maintainability: UI layout changes do not require altering or recompiling core backend business logic.
Collaboration Friendly: UI/UX designers can work directly with the template files without deep knowledge of server-side application logic.
Cleaner Presentation Code: Eliminates messy Java code responsible for outputting raw HTML tags.

Sunday, 11 August 2013

Concrete Table Inheritance Design Pattern

🚀 Enjoying This Tutorial?

Subscribe to Ram N Java for more easy-to-follow software architecture and Java tutorials!

🔔 Subscribe Now

What is Concrete Table Inheritance?

The Concrete Table Inheritance pattern is an object-relational structural pattern from Martin Fowler's Patterns of Enterprise Application Architecture. It represents an inheritance hierarchy by creating exactly one database table for each concrete class.

The Problem: Mapping Inheritance to Relational Databases

Relational databases do not have a native concept of object-oriented inheritance. When you have classes extending one another, you need a strategy to map those classes into tables and columns.

Step-by-Step Example

Let's look at an inheritance hierarchy:

Player (Abstract Superclass): Contains the attribute name.
Footballer (Concrete Class): Inherits from Player and adds club.
Cricketer (Concrete Class): Inherits from Player and adds batting_average.
Bowler (Concrete Class): Inherits from Cricketer and adds bowling_average.

Database Table Design:

footballers table: name, club
cricketers table: name, batting_average
bowlers table: name, batting_average, bowling_average

Key Takeaways

No table is created for the abstract Player class.
Each concrete table contains all inherited and declared fields.
Reading single entities is fast because no JOIN operations across parent tables are required.

What is the Single Table Inheritance Pattern?

The Single Table Inheritance pattern is an object-relational structural pattern from Martin Fowler's Patterns of Enterprise Application Architecture. It represents an entire inheritance hierarchy of classes within one single database table containing columns for all fields across all classes.

Why Do We Need It?

Relational databases do not support object-oriented inheritance natively. When multiple subclasses inherit from a common parent class, we need a clean strategy to store their shared and specific properties in relational tables.

Beginner-Friendly Example

Consider an employee management hierarchy:

Employee (Superclass): Contains common fields: employee_id, name, phone, email, and type (discriminator).
Salaried Employee (Subclass): Inherits from Employee and adds salary.
Hourly Employee (Subclass): Inherits from Employee and adds hours and rate.

Database Table Structure:

Instead of creating multiple tables, we map all classes into a single employee table:

Columns: employee_id, name, phone, email, type, salary, rate, hours
For a salaried employee, the rate and hours columns remain NULL.
For an hourly employee, the salary column remains NULL.
The type column identifies which subclass the row represents.

Key Advantages

Fast Queries: No SQL JOIN operations are needed to retrieve subclass data.
Simple Schema: Everything resides in a single table, simplifying data management.
Easy Refactoring: Moving fields up or down the hierarchy does not require altering database table structures.