LearningTree

Additional Design
Considerations

Programming paradigms, generative approaches, annotations, AOP, and cross-cutting concerns in software architecture.

Chapter One

Programming Language Features & Paradigms to Reduce Complexity

Design patterns and principles can be realized through real tools, technologies, and programming language features. Generative approaches reduce boilerplate, while language paradigms enforce correctness at the type-system level — both directly reduce complexity in software architecture.

Generative Creation of Components

Instead of writing repetitive code by hand, generative approaches let you describe what you want at a higher level — and the tooling produces the actual code for you.

→ Use macros, templates, schemas, or transpilers as your source
→ Eliminate manual boilerplate — less code to write and maintain
→ Get consistent output across multiple languages and platforms
→ Keep a single source of truth that enforces DRY automatically

⚙️

Macros

C/C++ Preprocessor — named fragments replaced at compile time
Enforce DRY by expanding repetitive code patterns automatically
Result is high-performance runtime code

📄

Template-Based Generators

JET — Java Emitter Templates
JSP / JSF — Jakarta Server Pages / Faces
Thymeleaf, FreeMarker — server-side Java templating
Follows DRY + SoC; output is static & high performance

🔄

Transpilers

TypeScript → JavaScript (adds type safety)
Wt — C++ Web Toolkit
JWt — Java Web Toolkit
Cross-platform: Xamarin, React Native, Flutter, Phone Gap

Macros — C/C++ Preprocessor Example

C/C++ macros let you define a reusable fragment once and expand it everywhere at compile time. The preprocessor replaces every occurrence before the compiler even sees the code — zero runtime overhead, pure DRY.

❌ Without Macros — Repeated Code

Same bounds-check duplicated everywhere

void setTemperature(int val) {
if (val < MIN || val > MAX) {
printf("Error: out of range\n");
return;
  }
  temperature = val;
}
void setPressure(int val) {
if (val < MIN || val > MAX) {
printf("Error: out of range\n");
return;
  }
  pressure = val;
}

✅ With Macros — Define Once, Reuse

Macro expands the check at compile time

// Define the macro once #define CHECK_RANGE(val, min, max) \
if ((val) < (min) || (val) > (max)) { \
printf("Error: %d out of range\n", val); \
return; \
  }
// Reuse everywhere — DRY void setTemperature(int val) {
CHECK_RANGE(val, -40, 125);
  temperature = val;
}
void setPressure(int val) {
CHECK_RANGE(val, 0, 1000);
  pressure = val;
}

Trade-off: Macros are powerful but have no type safety — the preprocessor does plain text substitution. Use them for small, well-defined patterns; prefer inline functions or templates in modern C++ for complex logic.

Template-Based Generators — Thymeleaf Example

Template engines mix static HTML with dynamic placeholders. At build or request time the engine fills in the data and outputs pure HTML — the template is the single source of truth for layout, while the data comes from the backend.

Thymeleaf Template (source)

HTML + Thymeleaf expressions

<!-- product-list.html -->
<table>
  <tr th:each="p : ${products}">
    <td th:text="${p.name}">Name</td>
    <td th:text="${p.price}">0.00</td>
    <td>
      <span th:if="${p.inStock}" th:text="'In Stock'"></span>
      <span th:unless="${p.inStock}" th:text="'Sold Out'"></span>
    </td>
  </tr>
</table>

Generated HTML (output)

Pure HTML — served to the browser

<!-- rendered at request time -->
<table>
  <tr>
    <td>Coffee Mug</td>
    <td>19.99</td>
    <td><span>In Stock</span></td>
  </tr>
  <tr>
    <td>Laptop Stand</td>
    <td>49.99</td>
    <td><span>Sold Out</span></td>
  </tr>
</table>

SoC in action: The designer owns the HTML template; the developer owns the data model. Neither touches the other's work — changes to layout don't break logic and vice versa.

Transpilers — TypeScript → JavaScript

TypeScript adds a compile-time type system on top of JavaScript. The transpiler strips types and outputs standard JS — catching entire classes of bugs before runtime at zero cost to performance.

TypeScript — Source (typed)

class Product {
constructor(
public name: string,
public price: number
) {}
displayDetails() {
    console.log(
`Product: ${this.name}, Price: ${this.price}`
);
  }
}
const product = new Product("Coffee Mug", 19);
product.displayDetails();

JavaScript — Generated (runtime-ready)

"use strict";
var Product = (function() {
function Product(name, price) {
    this.name = name;
    this.price = price;
  }
Product.prototype.display = function() {
    console.log(this.name + " costs $" + this.price);
  };
return Product;
})();
var coffeeMug = new Product("Coffee Mug", 20);
coffeeMug.display();

API-Based Generators — gRPC + Protocol Buffers

gRPC uses Protocol Buffers to define a .proto schema once, then generates type-safe client/server stubs for Java, Python, C#, Go, and more — enforcing contracts across service boundaries.

📄 product.proto — The Schema (source of truth)

Protocol Buffers schema — defined once

// product.proto syntax = "proto3";
package product;
// ── Messages ────────────────────── message Product {
string id    = 1;
string name  = 2;
double price = 3;
bool inStock = 4;
}
message ProductRequest {
string id = 1;
}
message ProductListResponse {
repeated Product products = 1;
}
// ── Service ─────────────────────── service ProductService {
rpc GetProduct (ProductRequest)
returns (Product);
rpc ListProducts (ProductRequest)
returns (ProductListResponse);
}

⚙️ How it works

Define messages (data structures) and services (RPC methods) in one .proto file
Run protoc — the Protocol Buffer compiler — targeting any language
The compiler outputs type-safe stubs: data classes + client/server interfaces
All languages share the same contract — no drift, no manual mapping

DRY at the API level: One schema → Java, Python, C#, Go stubs. Change the .proto and regenerate — every language stays in sync automatically.

☕

Generate Java Code

protoc --java_out=. \
  --grpc-java_out=. \
  -I. product.proto

🐍

Generate Python Code

python -m grpc_tools.protoc \
  --python_out=. \
  --grpc_python_out=. \
  -I. product.proto

🔷

Generate C# Code

protoc --csharp_out=. \
  --grpc-csharp_out=. \
  -I. product.proto

Key Insight: Define the schema once → generate for every language. This is KISS + DRY applied at the inter-service contract level.

Programming Language Paradigms

Programming paradigms provide structural building blocks that manage complexity at different levels — from naming and grouping code, to enforcing type safety and memory ownership at compile time.

📦

Functions & Procedures

SRP, Modularity, SoC, DRY — core principles realized
Decompose behaviour into named, reusable units
Enable isolated testing and reasoning

🧬

OOP — Objects & Inheritance

Encapsulation, polymorphism, abstraction
Class hierarchies and interfaces
Modelling real-world domains in code

📂

Modules & Packages

Logical grouping of related code
Namespace isolation prevents naming conflicts
Enables independent compilation & deployment

🔒

Access Modifiers

public — accessible anywhere
private — class-only
protected — subclasses
internal — same assembly / package

Advanced Language Features

Modern languages go beyond basic paradigms with features that catch entire categories of errors at compile time — type systems, ownership models, async primitives, and optional types.

🏷️

Type Systems

Catch type errors at compile time before they reach production
C++: int, double, bool, string
Prevents misuse: string phone = 053… → compile error
Stronger types = fewer runtime surprises

🧲

Ownership Models

Memory safety: each object has a clear owner
Prevents memory leaks, dangling pointers, data races
Helps with concurrency: no shared mutable state
unique_ptr (single owner) vs shared_ptr (reference counted)

⏳

Promises & Futures

Async operations without blocking the main thread
JS: Promise.then(success, failure)
Chain multiple async results declaratively
Eliminates "callback hell" and race conditions

❓

Optionals

"Expect Errors" principle — Postel's Law in code
Java: Optional<User>
Check presence before access — avoids NPEs
Makes absence of a value explicit in the type system

📋 Chapter 1 — Summary

Generative creation — Macros, templates, transpilers, and API generators (gRPC) produce code from higher-level descriptions, enforcing DRY and reducing boilerplate
Transpilers — TypeScript → JS adds type safety at zero runtime cost; cross-platform frameworks (Flutter, React Native) target multiple devices from one codebase
API-based generators — Define a .proto schema once → generate type-safe stubs for every language
Paradigms — Functions (SRP), OOP (encapsulation), Modules (namespace isolation), and Access Modifiers (information hiding) directly reduce complexity
Advanced features — Type systems, ownership models, promises/futures, and optionals catch entire categories of errors at compile time

Chapter Two

Annotations and Aspect-Oriented Programming

Annotations (decorators) add metadata to code elements, evaluated at compile or runtime. AOP separates cross-cutting concerns from business logic, weaving them in transparently — applying DRY, SoC, and OCP to concerns like logging, security, and performance monitoring.

Annotations (Decorators) — Concept

🏷️

What are Annotations?

Decorate functions, classes, methods, or properties with metadata
Evaluated by an annotation processor at compile time or runtime
Provide an abstraction layer to manage complexity
Enable cleaner, more concise, and more maintainable code
Help build more reliable and scalable systems

Compile-Time — Lombok Example

Java + Lombok — Code Generation via Annotations

@Getter @Setter @AllArgsConstructor @NoArgsConstructor @ToString public class Product {
private String id;
private String name;
private double price;
}
// → Lombok generates all getters, setters, //   constructors, and toString() at compile time

Annotations — Runtime Examples

Runtime annotations are evaluated by frameworks at startup or during execution. They wire dependencies, map objects to database tables, expose REST endpoints, and more — all without manual boilerplate.

Spring DI — @Bean Configuration

Runtime — Spring Container wires beans at startup

@Configuration public class AppConfig {
@Bean public NotificationService notificationService() {
return new NotificationService();
  }
@Bean public ProductService productService(NotificationService ns) {
return new ProductService(ns); // injected
}
}

Hibernate ORM — @Entity Mapping

Runtime — Hibernate maps objects to database tables

@Entity @Table(name = "employees")
public class Employee {
@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "id")
private int id;
@Column(name = "first_name")
private String firstName;
@Column(name = "email")
private String email;
}

Aspect-Oriented Programming (AOP)

AOP increases modularity by separating cross-cutting concerns (logging, security, transaction management) from business logic. The concern logic is defined once in an Aspect and "woven" into business code at compile or runtime.

🎯

What is AOP?

Increases modularity by separating cross-cutting concerns
Weaves concern logic into business logic at compile or runtime
Applies DRY + SoC + OCP to concerns like logging & security

🔑

Key Concepts

Aspect — component encapsulating cross-cutting logic
Advice — the action to perform (before, after, around)
Join Point — point in execution where advice is applied
Pointcut — expression to select matching join points

✅

Benefits

Business logic free of cross-cutting noise
Single place to change concern behaviour
Cleaner, more readable service classes
More reliable and maintainable systems

AOP — Weaving Aspects into Business Logic

AOP in Practice — Before & After

❌ Before AOP — Logging Mixed In

Logging duplicated in every service method

@Service public class ProductService {
public void updateInventory(Long id, int stock) {
// manually log every service call...
logger.info("updateInventory called");
long start = System.currentTimeMillis();
// business logic here
logger.info("Took " + (System.currentTimeMillis() - start));
  }
}
@Service public class OrderService {
public void processOrder(Long orderId) {
// same logging boilerplate repeated...
logger.info("processOrder called");
long start = System.currentTimeMillis();
// business logic here
logger.info("Took " + (System.currentTimeMillis() - start));
  }
}

✅ After AOP — Aspect Handles Logging

Logging defined once, woven by Spring AOP

@Aspect @Component public class ExecutionTimeAspect {
@Around("@annotation(LogExecutionTime)")
public Object logTime(
ProceedingJoinPoint joinPoint
  ) throws Throwable {
long start = System.currentTimeMillis();
Object result = joinPoint.proceed();
long elapsed = System.currentTimeMillis() - start;
    System.out.println(
      joinPoint.getSignature()
      + " executed in " + elapsed + "ms");
return result;
  }
}

Result: Services simply annotate methods with @LogExecutionTime — no logging logic in business code. The aspect is "woven in" by the Spring AOP framework at runtime, keeping business logic clean and cross-cutting concerns centralized.

📋 Chapter 2 — Summary

Annotations — Metadata decorators evaluated at compile time (Lombok: @Getter, @Setter) or runtime (Spring: @Bean, @Configuration; Hibernate: @Entity, @Column)
Compile-time annotations generate code automatically (getters, setters, constructors) — eliminating boilerplate
Runtime annotations wire dependencies, map ORM entities, expose REST endpoints — all without manual configuration
AOP — Separates cross-cutting concerns (logging, security, transactions) from business logic via Aspects
AOP Key Concepts: Aspect (the concern module), Advice (the action), Join Point (where it applies), Pointcut (the selector expression)
Benefits: DRY + SoC + OCP — define each concern once, change it in one place, business code stays clean

Chapter Three

Cross-Cutting Concerns and Concepts

Every system has concerns that don't belong to a single component — they span the entire architecture. These are called cross-cutting concerns.

📖

What are they?

Aspects of the system that affect multiple components simultaneously
Cannot be cleanly isolated into a single independent module
Arise naturally from quality requirements (security, performance, reliability)

⚠️

The Problem

If hard-coded everywhere → violates DRY & SoC
Logic gets scattered across many components
A single change (e.g. log format) requires touching every class
Testing becomes difficult — concerns are tangled with business logic

✅

The Solution

Identify and centralise each concern in one place
Use AOP, frameworks, or dedicated infrastructure modules
Apply consistently — every component benefits automatically
Change once → propagates everywhere

Cross-Cutting Concerns — Cutting Through All Components

Common Cross-Cutting Concerns — Overview

Persistence

Error Handling

Authentication

Authorization

I18N

Communication

GUI / UX

Business Rules

Logging

Caching

Concurrency

"Cross-cutting concerns cannot be easily separated into independent components — they may violate DRY/SoC and can lead to code scattered across different parts of the system."

Persistence

Persist data from volatile memory to permanent storage. The goal is to decouple business domain from database infrastructure and provide a single persistence solution for the entire application.

💾

What & Why

Persist data from volatile memory to permanent storage
Decouple business domain from database infrastructure
Abstract database interactions into high-level object operations
Provide a single persistence solution for the entire application

🗄️

ORM Framework Examples

Hibernate — Java
Entity Framework — .NET
Sequelize — Node.js
SQLAlchemy — Python

relational key/value file-based object-oriented graph-oriented document

Error Handling

A uniform, system-wide strategy for handling errors ensures predictable responses depending on category and severity, minimizes the blast radius of failures, and facilitates diagnosis.

⚠️

Goals of Error Handling

Predictable responses depending on category & severity
Differentiate between logical and technical errors
Minimize effects of errors on the system
Uniform & consistent across different technologies
Facilitate diagnosis — what / where / why
Error prevention — timely warning of identifiable problems

HTTP Status Codes

Code	Meaning
400	Bad Request
401	Unauthorized
404	Not Found
405	Method Not Allowed
500	Internal Server Error
503	Service Unavailable
507	Insufficient Storage

Security

Security is a first-class architectural concern — it should be designed in from the start, not retrofitted. It spans authentication, authorization, data integrity, confidentiality, and system availability.

🔑

Authentication & Authorization

Authentication — determine the sender's identity
Authorization — grant rights based on verified identity
Example: JWT tokens, OAuth 2.0, SAML

🛡️

Integrity & Confidentiality

Integrity — detect manipulation of data
Confidentiality — restrict unauthorized data access
Non-repudiation — prove authorship & validity

🏗️

Availability & Implementation

Availability — precautions against system failure
Frameworks: Spring Security (Java), Django (Python)
Libraries: OpenSSL, Bouncy Castle
Security should not be retrofitted — design in from the start

Internationalization (I18N)

Internationalization prepares an application to support multiple locales without code changes — covering formatting, currency, date/time, labels, cultural differences, and more.

🌍

I18N Dimensions

Formatting Currency Cultural differences Page layout Labels Documentation Error texts Shortcuts Date / Time / TZ Fonts Application logic Technical units

🔧

Implementation Tools

Resource Bundles — locale-specific key/value property files (Java)
i18next — widely used JS internationalization framework
Globalize — Unicode CLDR-based formatting
jQuery.I18n — plugin for web UIs

Communication and Messaging

Components and services must communicate — the communication style (sync vs. async, RPC vs. pub/sub) and technology choice are cross-cutting decisions that affect the entire system.

📡

Communication Styles

Synchronous — caller blocks until response received
Asynchronous — fire-and-forget; callback/event-based
Remote Procedure Call — gRPC, Apache Thrift, SOAP
Publish/Subscribe — decoupled topic-based messaging
Broadcast — one sender, many receivers

⚡

Technologies

Message Queues/Brokers: RabbitMQ, Kafka, Amazon SQS
RPC Standards: gRPC, Apache Thrift, SOAP
API Styles: REST, GraphQL
Networking Protocols: HTTP, RTP, UDP Multicast, WebSockets

User Interface and Ergonomics

The UI is where users interact with the system. A cross-cutting UI strategy ensures consistent styles, responsive layouts, accessibility (WCAG), and reusable components across all platforms.

🖥️

User Interface

Graphical, textual, voice-control interfaces
Can be adaptive and/or adaptable (device, user, situation)
Platforms: Mobile (iOS/Android), Desktop, Web, Touch monitors
Responsive UIs — pages rearrange based on screen size
Consistent stylesheets, reusable UI elements
WCAG — Web Content Accessibility Guidelines

🎨

Ergonomics

Optimize usability and user experience
Interaction flow and design
Reactivity (perceived performance)
Availability, protection against user errors
Learnability, self-descriptiveness
Adaptive design — different layouts per platform

Business Rules and Processes

Domain-specific business rules like "if process X is finished, then do Y" are often distributed across many components. This makes them hard to find, hard to change, and expensive to maintain. A centralized approach is better.

🚫

The Problem with Hard-Coded Rules

Domain conditions scattered across many components → low maintainability
Complex domain knowledge embedded in code → confusing code
Simple changes can become expensive → hard to estimate effort
Testing is difficult — business logic intertwined with infrastructure

Better: Centralized, explicit declaration using BRMS or workflow engines.

Drools — Business Rules Engine

Drools BRMS — Centralized business rules

package com.example.rules;
import com.example.PurchaseOrder;
rule "Apply 10% discount" when
$order: PurchaseOrder(amount > 100)
then
$order.setDiscount(
    $order.getAmount() * 0.10
  );
  System.out.println("Applied 10% discount");
end

Uber Cadence — Workflow Engine

public void processOrder(String orderId) {
  activities.validateOrder(orderId);
  activities.chargePayment(orderId);
  activities.updateInventory(orderId);
}

Cross-Cutting Concerns — Architecture Impact

📖

Definition

Aspects of the architecture affecting multiple components or the entire system
Usually cannot be easily separated into independent components
Often arise from fulfilling quality requirements

⚡

Challenge

Impact the entire system, adding technical constraints
May violate DRY/SoC if not managed
Can scatter code across different components
Hard-coded rules reduce maintainability

🛠️

Solution Approaches

AOP — weave cross-cutting logic at compile/runtime
Frameworks — Spring Security, Hibernate, i18next
BRMS — Drools for centralized business rules
Workflow Engines — Camunda, Uber Cadence

📋 Chapter 3 — Summary

Cross-cutting concerns — Architecture aspects that affect multiple components: persistence, error handling, security, I18N, communication, UI/UX, business rules
Persistence — Decouple domain from DB via ORM frameworks (Hibernate, Entity Framework, SQLAlchemy)
Error Handling — Uniform, predictable responses; differentiate logical vs. technical errors; facilitate diagnosis
Security — Authentication, authorization, integrity, confidentiality — design in from the start, never retrofit
I18N — Prepare for multiple locales (formatting, currency, date/time, labels) via resource bundles and I18N frameworks
Communication — Choose sync/async, RPC/pub-sub, REST/GraphQL — the style affects the entire system
UI & Ergonomics — Consistent styles, responsive layouts, WCAG accessibility, reusable components
Business Rules — Centralize with BRMS (Drools) or workflow engines (Camunda, Cadence) instead of scattering across code
Solution Approaches — AOP, dedicated frameworks, BRMS, and workflow engines keep cross-cutting concerns manageable

📚 Additional Resources

⚙️ Macros & Templating

C / C++ Macros

C/C++ macros are fragments of code that have been given a name. Whenever the name is used, it is replaced by the contents of the macro.

gcc.gnu.org/onlinedocs/cpp/Macros.html

Java Emitter Templates

JET — Java Emitter Templates for generating Java source code from templates.

eclipse.org — JET Tutorial

Jakarta Server Pages

Jakarta Server Pages (formerly JavaServer Pages) — server-side templating for Java web applications.

wikipedia.org — Jakarta Server Pages

Thymeleaf

A modern server-side Java template engine for both web and standalone environments.

thymeleaf.org

Apache FreeMarker™

A Java library to generate text output (HTML, e-mails, config files, source code) based on templates and changing data.

freemarker.apache.org

🔄 Transpilers & Cross-Platform

C++ Web Toolkit (Wt)

A web GUI library written in modern C++ for building interactive web applications.

webtoolkit.eu/wt

Java Web Toolkit (JWt)

A web GUI library in pure Java — write UI code once, run in the browser.

webtoolkit.eu/jwt

TypeScript

TypeScript is JavaScript with syntax for types — adds compile-time type safety to JS.

typescriptlang.org

React Native

An open-source UI framework for building Android, iOS, macOS, Windows, and Web apps from one codebase.

reactnative.dev

Flutter

An open-source UI SDK to develop cross-platform apps (Web, Android, iOS, Linux, macOS, Windows) from a single Dart codebase.

flutter.dev

📡 API & Communication

gRPC

A cross-platform, open-source, high-performance remote procedure call (RPC) framework originally developed at Google.

grpc.io

GraphQL

A data query and manipulation language for APIs — lets a client specify exactly the data it needs. A server can fetch from multiple sources and return a unified result.

graphql.org

Summary — All Chapters at a Glance

01 · PL Features & Paradigms

Reduce Complexity via Language

Leverage generics, annotations, lambdas & type systems
Macros & code generation eliminate boilerplate
Paradigms (OOP, FP) shape how you decompose problems

02 · Annotations & AOP

Aspect-Oriented Programming

Annotations add declarative metadata to code
AOP weaves cross-cutting logic (logging, security) at compile/runtime
Keeps business logic clean & focused

03 · Cross-Cutting Concerns

Architecture-Wide Aspects

Persistence, error handling, security, I18N, communication
Design security in from the start — never retrofit
Centralize rules via BRMS / workflow engines

Java Class → DB Column Mapping

Java Field (Employee.java)

DB Column (employees table)

@Id  @GeneratedValue

private int id

→

 PK AUTO_INCREMENT 

id  INT NOT NULL

@Column(name = "first_name")

private String firstName

→

first_name  VARCHAR(255)

@Column(name = "email")

private String email

→

email  VARCHAR(255)

Generated DDL — CREATE TABLE statement

-- Hibernate generates this DDL from your @Entity class CREATE TABLE employees (
id INT NOT NULL AUTO_INCREMENT,
first_name VARCHAR(255),
email VARCHAR(255),
PRIMARY KEY (id)
);
-- Sample INSERT (Hibernate translates save() call) INSERT INTO employees (first_name, email)
VALUES ('Alice', 'alice@example.com');
-- id = 1 (auto-generated) -- Sample SELECT (Hibernate translates findById(1)) SELECT * FROM employees WHERE id = 1;

Resulting Table — employees

id	first_name	email
1	Alice	alice@example.com
2	Bob	bob@example.com
3	Carol	carol@example.com

Key idea: Hibernate reads the annotations at runtime and handles all SQL automatically. You write Java objects — Hibernate writes the database.

Step 1 — One property file per locale (same keys, different values)

🇬🇧 messages_en.properties

# English app.title=Product Store welcome=Welcome, 0! item.price=Price: 0 btn.buy=Add to Cart error.notfound=Item not found currency=USD

🇩🇪 messages_de.properties

# Deutsch app.title=Produktshop welcome=Willkommen, 0! item.price=Preis: 0 btn.buy=In den Warenkorb error.notfound=Artikel nicht gefunden currency=EUR

🇫🇷 messages_fr.properties

# Français app.title=Boutique Produits welcome=Bienvenue, 0! item.price=Prix: 0 btn.buy=Ajouter au panier error.notfound=Article introuvable currency=EUR

Step 2 — Load the correct bundle at runtime based on user Locale

import java.util.Locale;
import java.util.ResourceBundle;
import java.text.MessageFormat;
public class I18nService {
public static String get(Locale locale, String key, Object... args) {
// Java picks the right .properties file automatically ResourceBundle bundle =
ResourceBundle.getBundle("messages", locale);
String pattern = bundle.getString(key);
return MessageFormat.format(pattern, args);
  }
public static void main(String[] args) {
// 🇬🇧 English Locale en = Locale.ENGLISH;
    System.out.println(get(en, "welcome", "Alice"));
    System.out.println(get(en, "btn.buy"));
// → Welcome, Alice! // → Add to Cart // 🇩🇪 German Locale de = Locale.GERMAN;
    System.out.println(get(de, "welcome", "Alice"));
    System.out.println(get(de, "btn.buy"));
// → Willkommen, Alice! // → In den Warenkorb // 🇫🇷 French Locale fr = Locale.FRENCH;
    System.out.println(get(fr, "welcome", "Alice"));
    System.out.println(get(fr, "btn.buy"));
// → Bienvenue, Alice! // → Ajouter au panier
}
}

Step 3 — Runtime output per locale

Key	🇬🇧 EN	🇩🇪 DE	🇫🇷 FR
app.title	Product Store	Produktshop	Boutique Produits
welcome	Welcome, Alice!	Willkommen, Alice!	Bienvenue, Alice!
btn.buy	Add to Cart	In den Warenkorb	Ajouter au panier
error.notfound	Item not found	Artikel nicht gefunden	Article introuvable

DRY in action: The application code never changes — only the .properties files differ. Adding a new language means adding one file, nothing else.