DEV Community: Charles Koffler

Introducing Flexibility Without Losing Structure in Clprolf

Charles Koffler — Fri, 27 Mar 2026 20:12:58 +0000

Why a structured approach doesn’t have to be a barrier to entry.

Introduction

When introducing a structured approach like Clprolf, a common concern appears quickly:

“Do I have to rewrite everything?”
“Does this change how I usually code?”
“Is this too strict for real-world usage?”

These concerns are legitimate.

Most real-world codebases are not perfectly structured.
They mix domain logic and technical details.
They evolve under constraints.

So the question becomes:

Can Clprolf exist without forcing a complete rewrite?

Starting From Existing Code

Clprolf is based on two simple principles:

a class is either technical or organized around a well-defined domain
inheritance must preserve that domain — otherwise, composition is used

These principles provide structure.

But they do not require starting from scratch.

You can start from existing code.

Even when a class mixes concerns,
it still has a primary role.

That role defines its nature.

A Flexible Entry Point

Clprolf can be used in a more flexible way by default, as the compiler operates in this mode.

In this mode:

existing code remains valid
no immediate refactoring is required
no additional annotations are necessary

The goal is not to enforce structure immediately,
but to make it available.

Structure Still Exists

Flexibility does not remove the model.

The same principles still apply.

Even in mixed code:

the primary role of a class remains identifiable
domain and technical concerns are still distinct in nature

Clprolf does not ignore structure.
It simply does not force it upfront.

Strict and Flexible Clprolf

This leads to two ways of using Clprolf:

a flexible usage, closer to common practices
a strict usage, with stronger structural guarantees

The difference is not in the model itself,
but in how strictly it is applied.

Strict Clprolf makes the separation explicit.
Flexible Clprolf allows it to remain implicit.

Compatibility Between Both

Both approaches are fully compatible.

strict code works in all cases
flexible code integrates without issue

There is no fragmentation.

Clprolf remains a single model,
regardless of how strictly it is applied.

Gradual Evolution

In practice, adoption becomes natural.

Developers can:

start with their existing code
observe where responsibilities become unclear
introduce structure where it brings value

No forced transition is required.

Clprolf can be adopted progressively.

Working With Existing Libraries

Clprolf does not require external code to follow its model.

Libraries, frameworks, and APIs can be used as they are.

What matters is how they are integrated.

The structure lives in your code,
not in the code you depend on.

Final Thought

Clprolf is not about forcing a new way of coding.

It is about providing a clearer structure
that can be applied when needed.

You don’t need to change everything to start.
You can start where you are —
and move toward more structure when it makes sense.

🧱 Two Structural Principles behind Clprolf

Charles Koffler — Tue, 24 Feb 2026 12:48:40 +0000

Prerequisites

Clprolf builds upon classical Object-Oriented Programming.

To fully follow this article, readers should already be familiar with:

the fundamentals of OOP,
inheritance and composition,
common design principles such as SRP,
the guideline “favor composition over inheritance”.

Foundational Principles of Clprolf

Clprolf is based on two core principles:

A class is either technical or organized around a well-defined class domain.
Inheritance must preserve the class domain; if it does not, composition is used instead.

These principles define how Clprolf structures components and relationships.

The class domain is the central subject around which a class is organized.
It defines what the class fundamentally represents and what it is responsible for.

For example:

A File class has a class domain related to file handling.
A Random class has a class domain related to random generation.
A Connection class has a class domain related to connection management.
A PdfGenerator class has a class domain related to PDF generation.

A technical class, by contrast, does not represent a conceptual domain.
It provides technical support (e.g., logging, parsing, low-level utilities).

Relation to SRP

The Single Responsibility Principle (SRP) states that a class should have only one reason to change.

The concept of class domain provides a structural way to think about responsibility:

If a class is organized around a single domain,
its evolution tends to follow that domain.

The two principles do not replace SRP.
They offer a way to reason about responsibility in terms of domain coherence.

Relation to “Favor Composition Over Inheritance”

The common guideline “favor composition over inheritance” is widely accepted.

The second principle provides a decision criterion:

If inheritance would introduce a different class domain,
then composition is used instead.

This does not remove judgment.
It clarifies how inheritance relates to the continuity of the class domain.

Closing

These two principles form the foundation of Clprolf.

They define how class roles are interpreted and how inheritance is understood within the language.

From them follow the structural distinctions and rules that Clprolf makes explicit.

Preventing Architectural Drift in Object-Oriented Systems — A Structural Approach with Clprolf

Charles Koffler — Sun, 15 Feb 2026 12:32:55 +0000

A Structural Locking Approach

Most large object-oriented systems do not collapse because of lack of expressiveness.

They collapse because of architectural drift.

Classes are created with clear intentions.
Over time, responsibilities expand.
Boundaries blur.
Layers mix.

The name remains.
The nature changes.

This is not a failure of developers.
It is a structural weakness of unconstrained class design.

Locking the Nature at Creation Time

What if the nature of a component had to be declared — and respected — from the start?

Clprolf enforces a simple but powerful rule:

Every component must explicitly belong to one of two ontological categories:

Domain (agent / model / abstraction)
Technical (worker_agent / infrastructure layer)

This is not a naming convention.
It is a structural constraint.

Once declared, a component cannot silently migrate across layers.
Inheritance must respect ontological boundaries.

Responsibility is not only described.
It is positioned.

From Description to Commitment

Traditional OOP:

class Sorter

Clprolf:

public class_for agent Sorter

The keyword for changes the mindset.

A class is no longer just a named container.
It is a construct for a declared ontological role.

This small syntactic shift forces a conceptual commitment.

Structural Discipline, Not Convention

Many architectural principles exist as guidelines:

separate concerns
avoid God Objects
respect layers
apply SOLID

Clprolf encodes part of this discipline directly into the language.

It does not rely only on human vigilance.

It reduces the surface for structural drift.

Why This Matters

In small systems, discipline is enough.

In large, long-lived systems, discipline erodes.

Clprolf introduces a structural locking mechanism that:

stabilizes ontological boundaries,
constrains illegitimate inheritance,
clarifies the meaning of a class from the start.

It does not reduce what can be built.

It changes how responsibility evolves.

And that difference can be decisive.

Getting Started with Clprolf: Structuring Responsibilities in OOP

Charles Koffler — Fri, 06 Feb 2026 17:35:37 +0000

📘 Getting Started with Clprolf

Prerequisites

Clprolf builds upon classical Object-Oriented Programming.

To fully benefit from this guide, readers should already be familiar with:

the fundamentals of OOP,
inheritance and composition,
basic design principles and common patterns.

Making Responsibilities Explicit

Clprolf is a language and framework designed to make architectural roles explicit.

In most object-oriented systems, separation of responsibilities relies on discipline.

Clprolf encodes that discipline structurally.

Every class declares what it is.

Foundational Principles of Clprolf

Clprolf is based on two core principles:

A class is either technical or organized around a well-defined class domain.
Inheritance must preserve the class domain; if it does not, composition is used instead.

These principles define how Clprolf structures components and relationships.

The class domain is the central subject around which a class is organized.
It defines what the class fundamentally represents and what it is responsible for.

A File class has a class domain related to file handling.

A technical class, by contrast, does not represent a conceptual domain.
It provides technical support (e.g., logging, parsing, low-level utilities).

1️⃣ Declaring a Role

Instead of writing:

public class OrderManager { }

In Clprolf you declare the role:

public class_for agent OrderProcessor { }

public class_for worker_agent OrderRepository { }

Each class has a declension (its architectural nature).

The core declensions are:

agent → business responsibility
worker_agent → technical execution
model → passive domain entity
information → technical data container
indef_obj → transitional, undefined role

2️⃣ Start Flexible: `indef_obj`

Clprolf does not require architectural clarity upfront.

You can begin with:

public class_for indef_obj OrderManager {
    public void process(Order order) {
        validate(order);
        save(order);
        notify(order);
    }
}

indef_obj represents a temporary state.

Refactoring can happen later.

3️⃣ Making Responsibilities Explicit

After identifying responsibilities:

Concern	Nature
Business validation	Business
Persistence	Technical
Notification	Technical

You refactor:

public class_for agent OrderProcessor {
    private OrderRepository repository;
    private OrderNotifier notifier;

    public void process(Order order) {
        validate(order);
        repository.save(order);
        notifier.notify(order);
    }
}

public class_for worker_agent OrderRepository { ... }
public class_for worker_agent OrderNotifier { ... }

The behavior is unchanged.
The architecture becomes explicit.

4️⃣ Structural Rules Are Enforced

Clprolf does not only suggest discipline.

It enforces structural coherence.

Example:

public class_for agent A1AnimalImpl nature AnimalWorker { }

This attempts to inherit a worker_agent from an agent.

Result:

ARCH-A1 => Class A1AnimalImpl:
the parent class should be an agent (AnimalWorker)

The equivalent Java code would compile:

public class A1AnimalImpl extends AnimalWorker { }

Clprolf rejects it as architecturally inconsistent.

6️⃣ What Clprolf Changes

Clprolf does not change:

algorithms
execution flow
runtime model

It changes:

role visibility
inheritance coherence
architectural guarantees

7️⃣ Philosophy in One Sentence

Clprolf encodes architectural responsibility at the language level
instead of leaving it to convention.

Refactoring Your Classes with Clprolf and `indef_obj`

Charles Koffler — Thu, 25 Dec 2025 14:51:46 +0000

Most developers agree on the Single Responsibility Principle (SRP).
The real difficulty is not what to do — it’s when to do it.

In real projects, we usually:

write code that works,
understand it better over time,
refactor when responsibilities become clearer.

Clprolf fits naturally into this workflow by supporting postponed architectural decisions through refactoring.

1️⃣ Starting from a Classic OOP Class

Let’s start with a very common example.
Nothing exotic. Just a class that works.

public class OrderManager {

    public void processOrder(Order order) {
        if (order.getTotal() <= 0) {
            throw new IllegalArgumentException("Invalid order");
        }

        saveToDatabase(order);
        logOrder(order);

        String message = formatConfirmation(order);
        sendEmail(message);
    }

    private void saveToDatabase(Order order) {
        System.out.println("Saving order " + order.getId());
    }

    private void logOrder(Order order) {
        System.out.println("Order processed: " + order.getId());
    }

    private String formatConfirmation(Order order) {
        return "Order #" + order.getId() + " confirmed";
    }

    private void sendEmail(String message) {
        System.out.println("Sending email: " + message);
    }
}

This class:

contains business rules,
handles persistence,
performs logging,
formats messages,
sends emails.

Everyone has written something like this.

2️⃣ Using Clprolf Without Thinking About Roles

In Clprolf, you can start exactly the same way.

No need to decide anything upfront.
You simply acknowledge that the architectural role is not yet clear.

public indef_obj OrderManager {

    public void processOrder(Order order) {
        if (order.getTotal() <= 0) {
            throw new IllegalArgumentException("Invalid order");
        }

        saveToDatabase(order);
        logOrder(order);

        String message = formatConfirmation(order);
        sendEmail(message);
    }

    private void saveToDatabase(Order order) { }
    private void logOrder(Order order) { }
    private String formatConfirmation(Order order) { return ""; }
    private void sendEmail(String message) { }
}

At this stage:

nothing is forced,
no architectural commitment is made,
the code can remain like this for a while.

indef_obj behaves like classic OOP — but consciously.

3️⃣ Applying SRP After Understanding the Code

Later — exactly like in a classic SRP refactoring — you realize that this class mixes different responsibilities.

Concern	Nature
Business decision	Business
Persistence	Technical
Logging	Technical
Formatting / I/O	Technical

This is where Clprolf becomes useful.

4️⃣ Refactoring into Explicit Responsibilities

Before (indef_obj)

OrderManager
 ├─ business rule
 ├─ persistence
 ├─ logging
 └─ notification


After (SRP made explicit)

OrderProcessor (agent)
 ├─ business decision

OrderRepository (worker_agent)
 └─ persistence

OrderNotifier (worker_agent)
 ├─ logging
 └─ messaging

🎯 Business Responsibility → `agent`

public agent OrderProcessor {

    private final OrderRepository repository;
    private final OrderNotifier notifier;

    public OrderProcessor(OrderRepository repository,
                          OrderNotifier notifier) {
        this.repository = repository;
        this.notifier = notifier;
    }

    public void process(Order order) {
        if (order.getTotal() <= 0) {
            throw new IllegalArgumentException("Invalid order");
        }

        repository.save(order);
        notifier.notify(order);
    }
}

The agent:

expresses business intent,
coordinates actions,
contains no technical details.

⚙️ Technical Responsibilities → `worker_agent`

public worker_agent OrderRepository {

    public void save(Order order) {
        System.out.println("Saving order " + order.getId());
    }
}

public worker_agent OrderNotifier {

    public void notify(Order order) {
        log(order);
        String message = format(order);
        send(message);
    }

    private void log(Order order) {
        System.out.println("Order processed: " + order.getId());
    }

    private String format(Order order) {
        return "Order #" + order.getId() + " confirmed";
    }

    private void send(String message) {
        System.out.println("Sending email: " + message);
    }
}

Workers may mix technical concerns freely:

I/O,
formatting,
logging,
infrastructure.

This is acceptable because business meaning remains in the agent.

5️⃣ What Changed — and What Didn’t

❌ What did not change

algorithms,
behavior,
performance,
expressivity.

✅ What did change

responsibilities became explicit,
architectural intent became visible,
future evolution became easier.

This is simply SRP applied structurally.

🧩 Conclusion

Clprolf does not ask developers to think harder —
and certainly not earlier.

It allows them to think when they are ready.

You can:

write code first,
understand it later,
refactor responsibilities when needed.

indef_obj is not a goal —
it is a temporary state that supports real-world development.

In that sense, Clprolf is not just a language.
It is a refactoring tool for architectural clarity.

A Global Model of How Classes Relate to Each Other in Clprolf

Charles Koffler — Sat, 06 Dec 2025 15:55:51 +0000

Clprolf introduces simple declensions (Agent, Worker, Abstraction…) that clarify the natural place of each class in a project.
Many developers asked for a global picture showing how these classes interact, how they depend on each other, and how domain-level classes stay cleanly separated from technical ones.

This article presents a conceptual model that explains:

how each class type fits into the architecture,
how domain classes interact with technical classes,
how pure abstractions differ from system abstractions,
and where @Forc_pract_code is used when crossing boundaries.

This is not a compiler rule-set.
It is simply a mental model that makes Clprolf’s design easier to understand and that helps classify new classes intuitively.

Below is the complete model, with diagram and detailed explanations.

This document provides a conceptual overview of how the main Clprolf declensions relate to each other in practice.
It is not a formal set of compiler rules, but a conceptual guide that helps developers understand how each declension fits into a coherent architectural model.

The goal is simple:
clarify the natural relationships between Agents, Abstractions, Workers, and System Abstractions,
and indicate where exceptions must be explicitly acknowledged through @Forc_pract_code.

                         ┌──────────────────────────────────────────┐
                         │              PURE ABSTRACTION            │
                         │ (concepts usable by ALL other roles)     │
                         │   - no workers                           │
                         │   - no system calls                      │
                         └───────────────────────┬──────────────────┘
                                                 │  used by anyone
                                                 ▼
                  ┌──────────────────────────────────────────────────┐
                  │                       AGENT                      │
                  │        (domain-level behavior & logic)           │
                  │                                                  │
                  │      [Optionally: simu_real_obj available]       │
                  └───────────────────────────┬──────────────────────┘
                                              │
                                              │ uses
                                              ▼
                 ┌──────────────────────────────────────────────────┐
                 │                   WORKER_AGENT                   │
                 │   (technical realization serving an Agent)       │
                 │                                                  │
                 │                                                  │
                 └──────────────────────────┬───────────────────────┘
                                             │
                                             │ calls
                                             ▼
         ┌────────────────────────────────────────────────────────────────┐
         │                        SYSTEM ABSTRACTION                      │
         │      (agent-like, system domain; may call workers or           │
         │       other system abstractions; uses @Forc_pract_code as      │
         │       declaration when needed)                                 │
         └────────────────────────────────┬───────────────────────────────┘
                                          │
                                          │ calls
                                          ▼
                   ┌──────────────────────────────────────────────────┐
                   │                        WORKER                    │
                   │   (low-level technical or native operations)     │
                   └──────────────────────────────────────────────────┘

1. Agent

An Agent represents a meaningful domain object.
It carries intention, behavior, and domain responsibility.

Agent rules

An Agent may call its Worker (its technical realization).
An Agent may call other Agents.
An Agent may use pure Abstractions.
An Agent must not directly use System Abstractions. If a domain object needs access to a system feature, its Worker handles it.

2. Worker

A Worker performs technical tasks on behalf of its Agent.

Typical examples include:

network senders/receivers,
file or database handlers,
UI adapters.

Worker rules

A Worker may call other Workers.
A Worker may use System Abstractions.
A Worker may use pure Abstractions.
A Worker may call its Agent to trigger domain operations (UI events, callbacks, etc.).
A Worker must not expose domain intelligence: its responsibility is purely technical.

Workers are the only declension allowed to bridge the domain world and system-level operations.

3. Pure Abstraction

A pure Abstraction is a conceptual type with no system interaction.
Its behavior is fully defined by logic, data, or mathematical structure.

Examples: collections, geometry, colors, numeric models, conceptual structures.

Pure Abstraction rules

It may call other pure Abstractions.
It may call Agents (same declension family).
It must not use System Abstractions.
It must not use Workers.
It normally does not have a Worker: memory itself provides the “technical realization”.

Pure Abstractions represent stable logic that does not depend on the environment.

4. System Abstraction

A System Abstraction is an abstraction that simulates a system resource or capability.

Examples:

Streams
Channels
Sockets
Threads
File abstractions

These objects have conceptual methods (e.g., read, write, open) but their internal realization requires system-level operations provided by a Worker.

System Abstraction rules

A System Abstraction may use its Worker for technical realization.
A System Abstraction may call other System Abstractions only when they belong to the same underlying domain of functionality.
A System Abstraction may not call Agents.
Any usage of external system abstractions or utilities must be annotated with @Forc_pract_code.

The annotation confirms that the developer intentionally breaks the purity of the abstraction for practical reasons.

5. Exceptions with `@Forc_pract_code`

Whenever a class must call an element that normally belongs outside its allowed scope, the developer must explicitly annotate the class or method with:

@Forc_pract_code

This annotation expresses:

“I acknowledge that I am breaking the usual boundaries.”
“This is done for practical, controlled reasons.”
“This code is still correct within the intended model.”

Typical cases:

A System Abstraction relying on a helper System Abstraction indirectly.
A System Abstraction using a utility normally reserved to another domain.
Exceptional bridging between system-level abstractions.

6. Summary Table

Here is a simplified summary of allowed direct usage:

From / To	Agent	Worker	Pure Abstraction	System Abstraction
Agent	✔	✔	✔	✘
Worker	✔ (its Agent)	✔	✔	✔
Pure Abstraction	✔	✘	✔	✘
System Abstraction	✘	✔ (its Worker)	✔	✔ (same domain)

@Forc_pract_code may be added where exceptions are intentional and justified.

7. Purpose of This Model

This article does not add rules to the compiler.
It simply clarifies the intuitive structure that naturally emerges from Clprolf:

Agents = meaning
Workers = execution
Pure Abstractions = logic
System Abstractions = simulated system capabilities

This model helps developers:

classify new classes correctly,
avoid mixing concerns accidentally,
navigate and design complex systems more safely,
recognize patterns inside existing codebases (e.g., Java libraries),
understand how system-oriented classes are structured internally.

Separating Class Responsibilities with Clprolf

Charles Koffler — Thu, 04 Dec 2025 18:06:42 +0000

Designing clean, well-structured classes is a central challenge in object-oriented programming.
Clprolf addresses this by introducing declensions — a simple way to express the nature of a class and the domain it belongs to.

Rather than replacing your existing architecture, Clprolf integrates naturally with it.
Your repositories, services, controllers, entities, abstractions all stay where they are.
You simply add a declension to each class, and Clprolf helps maintain a clear separation between domains.

🌐 Why the term “declension”?

The word declension is borrowed from languages, where a word changes form depending on its use while keeping the same core identity.
Clprolf applies the idea to objects: a declension tells whether a class belongs to the business/domain layer (agent) or the technical layer (worker_agent).

Within a declension, synonyms simply refine the intention without changing the domain:

agent → active business element
abstraction → conceptual domain element
simu_real_obj → active entity in a simulation

It’s a compact way to express:
one architectural identity, several possible nuances — just like in natural languages.

1) Two main declensions for two domains

Every class with methods must declare its domain through one of two declensions:

🔹 agent

Business logic, domain concepts, abstractions, simulation entities.

🔹 worker_agent

Technical components: repositories, display logic, file operations, system interactions, launchers.

This approach keeps the business layer and the technical layer cleanly separated.

2) Synonyms to express different perspectives

Declensions also have synonyms, allowing the developer to choose the term that best reflects the class’s intention.

For the agent declension:

agent — main, general-purpose synonym
abstraction — for conceptual or structural elements (List, Button, Color, Connection)

A List is an abstraction, not a technical component.

simu_real_obj — for objects inside a simulation

For worker_agent:

worker_agent — main synonym
comp_as_worker — same meaning, with a simulation nuance

These synonyms do not change the actual domain; they simply refine how the developer describes their component.

One nice effect of the system is that developers rarely disagree on which synonym to use.
The distinctions are natural, non-overlapping, and easy to recognize: “this is an abstraction”, “this is a business agent”, “this belongs to a simulation”.
The result is both expressive and stable — a balance that many object-oriented developers appreciate.

3) Declensions work with your existing components

Clprolf does not replace Service, Repository, or Controller roles.
It adds a declension on top of them to ensure consistency.

A typical mapping is:

Component type	Declension
Repository / DAO	worker_agent
Service	agent
Controller	agent

Clprolf then supervises inheritance between these components indirectly:

A worker_agent cannot inherit from an agent → a Repository cannot inherit from a Service
An agent cannot inherit from a technical class
Two synonyms of the same declension may inherit, but a warning indicates differing perspectives

This approach ensures that your components remain clean and simple, and remain in their intended domain.

Note:
Different teams may interpret controllers differently.
Clprolf maps them to agent because they coordinate domain behavior rather than executing technical work. Still, if a particular architecture treats controllers as purely technical endpoints, using worker_agent is acceptable as long as the choice remains consistent across the application.

4) Domain consistency through inheritance rules

Because the domain is declared in the class, inheritance remains coherent.

✔ Allowed

abstraction → agent (same declension, different synonym → warning)

❌ Not allowed

worker_agent → agent
DAO → Service
Technical → Business

This prevents accidental cross-domain inheritance and avoids mixing responsibilities over time.

Clprolf does not redefine object-oriented programming — it simply guides component relationships so domain boundaries remain intact.

5) Why this is useful in practice

With Clprolf declensions:

your business logic and technical logic stay separated,
your class hierarchy cannot drift into inconsistent states,
abstraction objects stay abstractions,
technical classes cannot absorb business code,
and domain organization becomes clearer for any developer joining the project.

Clprolf keeps your components predictable, readable, and consistent.

6) Class declensions and SOLID

Declensions are only one part of Clprolf, but they support a powerful idea:

Each object expresses a unique and well-defined kind of work.

This aligns naturally with the Single Responsibility Principle.
A class belongs to exactly one domain, expressed through its declension.
Its methods then follow that domain.

Furthermore, Clprolf interfaces can target these class roles, allowing version and capacity interfaces to match the intended domain of the classes that implement them.

This gives developers a clear, structured way to define both what an object is and what kind of work it performs, while remaining fully compatible with established SOLID principles.

📌 How does this relate to DDD or Clean Architecture?

Clprolf does not replace DDD or Clean Architecture — it works alongside them.
DDD focuses on how to model the domain, while Clean Architecture defines how to separate the domain from technical concerns.

Clprolf is closest to Clean Architecture in spirit, but with a key difference:
it enforces architecturally clean boundaries at the language level.

Domain classes (agent) and technical classes (worker_agent) cannot be mixed through inheritance.
Abstractions (abstraction) remain structural domain concepts, never technical utilities.
Technical components cannot “leak” into domain logic by accident.

Where DDD and Clean Architecture rely on discipline and conventions,
Clprolf turns those boundaries into compiler-checked guarantees, ensuring that domain and technical layers stay clean over time — without additional frameworks or architectural policing.

📌 Summary comparison

Approach	Main focus	Boundary enforcement
DDD	Domain modelling, ubiquitous language	By conventions and team discipline
Clean Architecture	Separation of domain vs technical layers	By guidelines, patterns, and project structure
Clprolf	Declensions: domain vs technical roles	Compiler-checked, enforced by the language

📌 Is Clprolf too rigid?

Clprolf may appear strict at first because it enforces a clear boundary between domain classes (agent) and technical classes (worker_agent).
But this strictness is no greater than what developers already follow with the Single Responsibility Principle.

In practice, Clprolf simply makes explicit what good design requires anyway:
a class should have one kind of responsibility, and belong to one area of the architecture.
Declensions formalize this separation so it remains consistent over time — without adding more constraints than SRP itself.

Examples with the Clprolf Java Framework (one-to-one with the Clprolf language declensions)

Below are a few simple examples using the Clprolf Java framework. They demonstrate how declensions integrate naturally into everyday classes.

✅ Example 1 — A simple Service using a Repository

@Agent
public class OrderService {

    private final OrderRepository repository = new OrderRepository();

    public void validateAndStore(String orderId) {
        // Business logic
        System.out.println("Validating order " + orderId);

        // Technical operation delegated to a worker_agent
        repository.save(orderId);
    }
}

➡️ OrderService is pure business logic
➡️ The service uses a technical component, not the other way around

✅ Example 2 — A simple Repository (technical layer)

@Worker_agent
public class OrderRepository {

    public void save(String orderId) {
        System.out.println("Saving order " + orderId);
    }
}

➡️ OrderRepository is technical work
➡️ No business rules inside

❌ Example 3 — Forbidden inheritance (Repository → Service)

@Worker_agent
public class WrongRepo extends OrderService {
    // ❌ Compilation error:
    // A worker_agent cannot inherit from an agent.
}

Clprolf prevents mixing domains through inheritance.
A technical class cannot extend a business class.

✅ Example 4 — A simple real Agent (clean example)

@Agent
public class Animal {

    public void eat(String food) {
        System.out.println("The animal eats " + food);
    }
}

➡️ A real domain object
➡️ No abstraction tricks, no simulation complexity
➡️ Just a clean agent example

✅ Example 5 - A Checkout service

@Agent
public class CheckoutService {

    private final OrderRepository orders = new OrderRepository();
    private final PaymentRepository payments = new PaymentRepository();

    public void checkout(String orderId) {
        orders.save(orderId);
        payments.process(orderId); // Another technical operation
    }
}

🟦 What these examples demonstrate

You keep your usual components: Service, Repository, Controller…
Clprolf adds @agent or @Worker_agent on top
The service naturally contains its technical worker (Repository)
Inheritance stays clean: business ←→ technical separation is preserved
The domain is easier to maintain and reason about

🟩 Final line

Declensions are one part of Clprolf: they define objects with a single, clear type of work, support solid domain separation, remain compatible with SOLID, and can even be targeted by Clprolf interfaces.

📚 Official documentation

Full Clprolf manual, specs, and framework:
https://github.com/charleskoffler/clprolf

“One Reason to Change” — The Forgotten Logic Behind the SRP (and How Clprolf Completes It)

Charles Koffler — Thu, 13 Nov 2025 15:26:48 +0000

1. The SRP is not wrong, just incomplete

The Single Responsibility Principle (SRP) is quoted everywhere.
But behind its mythical sentence —

“A class should have only one reason to change.”

— lies a deep ambiguity.
What is a reason? Whose responsibility are we talking about?
And why one?

The SRP was never false — it was simply unfinished.
It sensed a truth, but never named it.
That’s where Clprolf steps in: not to oppose, but to complete the story.

2. What the SRP really implies (if we take it seriously)

If all methods of a class must change for the same reason,
then they all participate in the same work.

That alone leads to two clear consequences:

Technical and business layers must be separated.
A technical change (like a database driver) shouldn’t affect business rules.
A business rule shouldn’t require refactoring a technical class.
Each class must have a unique theme — its own nature.
That theme unites all methods, gives the class its identity,
and defines its natural scope.

In other words: respecting SRP means respecting both
layer separation and nature unity.

3. Responsibility belongs to the class, not to its methods

Responsibility doesn’t live in methods.
Each method performs a specific action —
but the class itself carries a single overarching responsibility.

Example:
A Doctor class has one responsibility — the health of its patients.
Its methods (takeBloodPressure(), prescribeTreatment(), analyzeResults())
each do something different,
but they all serve the same responsibility.

Methods express the responsibility — they don’t define it.
They are the visible forms of a single coherent duty.

Confusing method-level actions with class-level responsibility
is what leads to fragmentation, over-engineering, and endless SRP debates.

⚠️ Misinterpretation Alert — SRP ≠ “one method per class”

A widespread misunderstanding asserts that obeying the SRP means:

“A class should do only one thing, so it should have only one method.”

This is a complete misunderstanding of the principle.
An object is defined by a set of related operations belonging to the same domain.
A class may (and should) have many methods —
as long as they all serve the same nature.

SRP is violated when a class mixes domains,
not when it has multiple methods within the same one.

This confusion came from treating “responsibility” as an action,
instead of what it truly is:
a conceptual duty flowing from the class’s nature.

4. The chain of meaning: Change → Responsibility → Nature

A class doesn’t change for arbitrary reasons.
It changes because its responsibility evolves.
And that responsibility exists only as an expression of the class’s nature.

Example:
The way a doctor takes blood pressure might change —
a new device, a new procedure —
but the reason stays the same: maintaining the patient’s health.

The technical details evolve,
but the responsibility remains constant,
because it’s rooted in the same nature.

So when we say “one reason to change”,
we are really saying:

Change belongs to responsibility, and responsibility belongs to nature.

When that hierarchy is respected,
evolution no longer breaks coherence — it confirms it.

5. Where Clprolf brings clarity

This is exactly where Clprolf goes beyond discussion.
Clprolf doesn’t interpret the SRP — it makes it concrete.

In Clprolf:

every class explicitly declares its nature;
its responsibility flows directly from that nature;
and its methods remain coherent by design.

You don’t try to obey the SRP —
you can’t violate it anymore.

In Clprolf, the SRP stops being a principle.
It becomes a structural fact of the language.

By grounding responsibility in nature, Clprolf turns moral advice into measurable architecture.
It brings peace where other frameworks bring anxiety —
and replaces “clean code” slogans with genuine clarity.

6. Conclusion — From principle to clarity

The SRP was never the enemy.
It simply stopped halfway.

It pointed toward the need for a single reason to change,
but never defined where that reason comes from.

Today, with Clprolf, we can finally complete the sentence:

“A class should have only one reason to change —
because it has only one nature.”

And at last, the debate can end.

💡 Summary Table

Concept	Description	Example
Nature	What the class is	`Doctor`
Responsibility	What the class does as a whole	Health of patients
Method	How it does it concretely	`takeBloodPressure()`

When nature, responsibility, and methods stay aligned,
change becomes natural, predictable, and never chaotic.

🔎 **Bonus — What SRP really means at the method level**

SRP does have a meaningful application at the method level —
but almost never in the way people describe it.

The most important rule is the simplest one:

⭐ **A business method must never contain technical code.

A technical method must never contain business logic.**

This is the real source of method-level SRP violations.

When a method mixes domain logic with infrastructure logic,
it immediately acquires two distinct reasons to change:

the domain rules may evolve independently,
the technical concerns (I/O, persistence, networking…) may evolve independently.

This is a textbook SRP violation —
and the most dangerous and common one.

✔ What does not violate SRP

Most of what people call “SRP violations” are not violations at all:

a method that is long,
a method with several internal steps,
a method that has sub-operations,
a method that has an inline algorithm.

All these cases are simply the decomposition
of one single algorithmic intention.

Algorithmic steps do not create multiple responsibilities.
They are not “reasons to change” — they are implementation detail.

SRP is about cross-domain evolution, not
micro-method minimalism.

⭐ Clprolf makes method-level SRP automatic

In Clprolf, method-level SRP is guaranteed structurally:

An agent may contain only business logic.
A worker_agent may contain only technical logic.
A model contains no logic at all.
An abstraction has no domain-specific code.

Because a class has one nature,
its methods cannot cross boundaries.

✔ No business logic in technical methods

✔ No technical logic in business methods

✔ No cross-layer pollution

✔ No accidental reasons to change

The only remaining “method-level SRP” cases are pure algorithmic ones —
and these are naturally handled by regular refactoring:
extracting a method when internal parts evolve independently.

🧭 Summary

Method-level SRP = prevent cross-domain mixing.
Algorithmic decomposition is not a responsibility issue.

Clprolf enforces domain purity by design,
so method-level SRP becomes:

objective,
structural,
automatic,
and no longer a subjective stylistic debate.

🧠 About Clprolf

Clprolf (Clear Programming Language & Framework) is a Java-compatible language that brings semantic clarity to software design.
It redefines classes through declared roles and natures,
bridging the gap between human meaning and technical structure.

Learn more: github.com/charleskoffler/clprolf

Final note – Change as a Sign of Duty

Change, in the end, is not a sign of instability.
It is the quiet proof that the class takes its duty seriously.
A class evolves not because it is flawed,
but because it remains faithful to its responsibility —
and to the mission that gives it meaning.

In the end, what the SRP truly meant was simple:
no mixing of layers,
no multiple inheritance,
and a clear, single meaning given to each class.

🗂️ Clprolf Directory Explorer — When Breadth-First Becomes Intuitive

Charles Koffler — Sun, 19 Oct 2025 21:24:37 +0000

Everyone knows that exploring directories can quickly turn into a messy technical exercise:
loops, recursion, stacks, file filters… and code that loses all readability.

With Clprolf, clarity is built-in.
You don’t just write code — you design agents, workers, and models that reflect what really happens.
Let’s see how a simple directory explorer can become a beautifully structured program.

💡 1. The Concept

We want to:

explore all subdirectories of a given folder,
in breadth-first order (level by level),
assign each directory a hierarchical ID,
and display the results cleanly.

Instead of mixing logic, display, and data handling,
Clprolf invites us to split them into roles.

Component	Declension	Responsibility
`Launcher`	`@Worker_agent`	Starts the exploration
`DirectoryExplorerImpl`	`@Agent`	Performs the exploration
`DirectoryExplorerWorkerImpl`	`@Worker_agent`	Displays results
`Directory`	`@Model`	Represents one directory node
`DirectoryExplorer` / `DirectoryExplorerWorker`	`@Version_inh`	Define contracts between roles

⚙️ 2. The Launcher

The entry point is as simple as it looks.
It prepares the environment and delegates the job to the proper agent.

@Worker_agent
public class Launcher {

    public static void main(String[] args) {
        @With_compat Path path = Paths.get(args.length > 0 ? args[0] : System.getProperty("user.home"));
        try { path = path.toRealPath(LinkOption.NOFOLLOW_LINKS); } catch (Exception ignored) {}

        if (!Files.isDirectory(path)) {
            System.err.println("Not a directory: " + path);
            System.exit(1);
        }

        @With_compat DirectoryExplorer explorer = new DirectoryExplorerImpl();
        explorer.breadthFirstFolders(path);
    }
}

It’s clear who does what:
this worker doesn’t explore — it simply launches the agent.

🧭 3. The Agent — `DirectoryExplorerImpl`

Here lies the real exploration logic.
The agent collaborates with a worker, manipulates a model, and manages a queue.

@Agent
public class DirectoryExplorerImpl implements @Contracts DirectoryExplorer {

    private @With_compat DirectoryExplorerWorker worker;

    public DirectoryExplorerImpl() {
        this.worker = new DirectoryExplorerWorkerImpl();
    }

    public void breadthFirstFolders(@With_compat Path directoryPath) {
        directoryPath = directoryPath.normalize().toAbsolutePath();

        @With_compat List<Directory> foldersList = new ArrayList<>();
        @With_compat Queue<Directory> directoryToExplore = new LinkedList<>();

        directoryToExplore.add(new Directory(directoryPath, List.of(0)));

        while (!directoryToExplore.isEmpty()) {
            Directory current = directoryToExplore.poll();
            foldersList.add(current);

            File[] files = current.getPath().toFile().listFiles();
            if (files != null) {
                int index = 0;
                for (File file : files) {
                    if (file.isDirectory()) {
                        List<Integer> newId = new ArrayList<>(current.getHierarchicalId());
                        newId.add(index);
                        directoryToExplore.add(new Directory(file.toPath().normalize().toAbsolutePath(), newId));
                        index++;
                    }
                }
            }
        }

        worker.displayResult(foldersList);
    }
}

Every part is crystal clear:

The queue defines a breadth-first traversal.
Each directory receives its own hierarchical ID.
The worker takes care of presentation.

No recursion, no confusion.

👷 4. The Worker Agent

Responsible for showing the result, not for computing it.
Again, we separate doing from showing.

@Worker_agent
public class DirectoryExplorerWorkerImpl implements @Contracts DirectoryExplorerWorker {

    public void displayResult(List<Directory> foldersList) {
        for (Directory dir : foldersList) {
            String display = formatId(dir.getHierarchicalId()) + " : " + dir.getPath();
            System.out.println(display);
        }
    }

    private String formatId(List<Integer> id) {
        return "(" + String.join(", ", id.stream().map(String::valueOf).toArray(String[]::new)) + ")";
    }
}

Simple, explicit, human-readable.

📦 5. The Model

A @Model in Clprolf is always clear:
it represents data, and nothing more.

@Model
public class Directory {
    private Path path;
    private List<Integer> hierarchicalId;

    public Directory(Path path, List<Integer> id) {
        this.path = path;
        this.hierarchicalId = id;
    }

    public Path getPath() { return path; }
    public List<Integer> getHierarchicalId() { return hierarchicalId; }
}

No logic, no side effects. Just structure.

🤝 6. The Contracts

@Agent
@Version_inh
public interface DirectoryExplorer {
    void breadthFirstFolders(Path directoryPath);
}

@Worker_agent
@Version_inh
public interface DirectoryExplorerWorker {
    void displayResult(List<Directory> foldersList);
}

Contracts make the collaboration explicit.
No hidden dependencies, no tight coupling — just clear communication.

🪶 7. Why it matters

Breadth-first exploration is only the example.
What matters here is how naturally the architecture expresses itself:

The launcher launches.
The agent explores.
The worker displays.
The model represents.
The contract binds.

Clprolf doesn’t just help you code — it helps you think.
The structure emerges from the intention.

✨ Final Thoughts

In classical Java, you might have written a single class doing everything.

In Clprolf, each role finds its natural place.
The result is simple, explicit, and readable — even for someone who never wrote Java before.

Clprolf brings clarity back into architecture,
and even the smallest utilities become examples of well-designed software.

☀️ WeatherApp MVC — When Clprolf Meets Spring MVC Philosophy

Charles Koffler — Sun, 05 Oct 2025 21:57:51 +0000

Everyone knows the MVC pattern.
But what if you could make it even clearer, more structurally explicit, and compatible with both desktop and web architectures?

That’s what Clprolf does —
it turns the philosophy of clarity-oriented programming into real, verifiable structure.

Let’s look at a simple example:
a WeatherApp written in Java + Clprolf annotations —
which behaves like a Spring MVC application,
but runs locally in Swing.

🧠 1. The Idea Behind It

In Spring MVC, a Controller receives a request,
calls a Repository or Service,
and returns a View.

In Clprolf, we do exactly the same —
but we explicitly declare the roles of each component.

Component	Clprolf Role	Description
`WeatherApp`	`@Worker_agent(Gender.STATIC)`	The system launcher (like Spring Boot main)
`WeatherController`	`@Agent`	The “brain” that coordinates the logic
`WeatherRepository`	`@Worker_agent`	Technical layer fetching data
`WeatherRenderer`	`@Worker_agent`	The View layer (UI and user input)

🏗️ 2. The Complete Code

package org.clprolf.examples.design_patterns.mvc;

import org.clprolf.framework.java.Gender;
import org.clprolf.framework.java.Worker_agent;

@Worker_agent(Gender.STATIC)
public class WeatherApp {
    public static void main(String[] args) {
        WeatherController controller = new WeatherController();
    }
}

🧩 Controller (Agent Layer)

package org.clprolf.examples.design_patterns.mvc;

import org.clprolf.framework.java.Agent;
import org.clprolf.framework.java.Gender;

@Agent(Gender.EXPERT_COMPONENT)
public class WeatherController {
    private WeatherRepository model;
    private WeatherRenderer view;

    public WeatherController() {
        model = new WeatherRepository();
        view = new WeatherRenderer(this);
    }

    public void giveTheWeather(String location){
        model.setLocation(location);
        model.fetchWeather();
        String forecast = model.getForecast();
        view.displayForecast(forecast);
    }
}

This class acts like a Spring @Controller:
it receives a request (giveTheWeather),
calls the repository,
and updates the view.

🎨 View (Worker Layer)

package org.clprolf.examples.design_patterns.mvc;

import java.awt.BorderLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.*;

import org.clprolf.framework.java.Agent;
import org.clprolf.framework.java.Contracts;
import org.clprolf.framework.java.Nature;
import org.clprolf.framework.java.Worker_agent;
import org.clprolf.framework.java.Advice;

@Worker_agent
public class WeatherRenderer {

    private JFrame frame;
    private JTextField locationField;
    private JTextArea forecastArea;
    private WeatherController expert;

    @Agent
    @Version_inh
    private static interface WindowObserver extends @Nature ActionListener { }

    @Agent
    private class WindowObserverImpl implements @Contracts WindowObserver {

        @Override
        public void actionPerformed(ActionEvent e) {
            String location = getLocationInput();
            this.expert.giveTheWeather(location);
        }
    }

    public WeatherRenderer(WeatherController expert) {
        this.expert = expert;
        prepareViewObjects();
    }

    protected void prepareViewObjects() {
        frame = new JFrame("Weather Forecast");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setSize(400, 200);

        JPanel panel = new JPanel(new BorderLayout());
        JLabel locationLabel = new JLabel("Enter Location:");
        locationField = new JTextField(20);
        locationField.addActionListener(new WindowObserverImpl());

        forecastArea = new JTextArea(5, 30);
        forecastArea.setEditable(false);

        panel.add(locationLabel, BorderLayout.NORTH);
        panel.add(locationField, BorderLayout.CENTER);
        panel.add(new JScrollPane(forecastArea), BorderLayout.SOUTH);

        frame.getContentPane().add(panel);
        frame.setVisible(true);
    }

    public String getLocationInput() {
        return locationField.getText();
    }

    public void displayForecast(String forecast) {
        forecastArea.setText(forecast);
    }
}

Here, the view acts like a web frontend.
It observes user input (capacity-inherited ActionListener)
and sends the event to the controller agent.

You could almost replace Swing with HTML/JavaScript
and it would behave the same way!

☁️ Repository (Technical Worker)

package org.clprolf.examples.design_patterns.mvc;

import org.clprolf.framework.java.Worker_agent;

@Worker_agent
class WeatherRepository {
    private String location;
    private String forecast;

    public void setLocation(String location) {
        this.location = location;
    }

    public void fetchWeather() {
        this.forecast = "Sunny with a chance of clouds";
    }

    public String getForecast() {
        return forecast;
    }
}

A pure worker: no intelligence, no UI — just technical work.
That’s exactly what a Repository or Service does in Spring MVC.

🔄 3. The MVC Flow

User (View) → WeatherRenderer (worker_agent)
             → WeatherController (agent)
             → WeatherRepository (worker_agent)
             → back to WeatherRenderer

The same logical flow as Spring MVC —
but here, everything runs locally and instantly.

🧠 4. Why It Matters

This example shows that Clprolf integrates seamlessly with existing patterns.
It doesn’t replace MVC, Spring, or OOP —
it simply clarifies and strengthens them.

In a Spring app, you’d just change the way communication happens
(HTTP + @GetMapping instead of direct calls) —
but your roles, responsibilities, and architecture remain identical.

💬 5. Final Thoughts

Clprolf makes architecture visible.
You no longer guess what a class is supposed to be:
you declare it — explicitly.

A Controller is an Agent.
A Repository is a Worker_agent.
A Launcher is a Static Worker_agent.
A View is also a Worker_agent — the interface between human and machine.

In short:
Clprolf doesn’t reinvent MVC — it makes it self-explanatory.

🧡 Summary

Traditional Role	Clprolf Equivalent	Layer
Controller	`@Agent`	Logic / Domain
Repository	`@Worker_agent`	Data / Technical
View	`@Worker_agent`	Presentation
Launcher	`@Worker_agent(Gender.STATIC)`	System entry

🌤️ “It acts as a living interface between human and machine —
the very essence of the worker_agent.”

That’s the clarity and beauty of Clprolf.

🐍 Revisiting Snake in Java with Clprolf — From Clear Code to Clear Game

Charles Koffler — Sat, 04 Oct 2025 18:23:40 +0000

What if writing a small game could prove that architecture can be both clean and alive?
Let’s revisit the classic Snake game — but built with Clprolf,
a paradigm that turns clarity into a coding language.

🧠 1. From OOP to Clarity-Oriented Programming

Clprolf isn’t a framework. It’s a language layer + methodology
that builds architectural meaning into Java itself.

Annotation	Role
`@Agent`	Domain logic — active and autonomous components
`@Worker_agent`	Technical performer (I/O, UI, OS, rendering)
`@Abstraction`	Conceptual contract or system-level interface
`@Model`	Passive structure, pure data
`@Underst`	A “thinking” method — where reasoning matters
`@Long_action`	A time-based or continuous process
`@With_compat`	Declares a safe compatibility link between agents

When you read Clprolf code, you see intent, not just syntax.

⚙️ 2. The Architecture of the Snake Game

The game has five layers — all explicit:

SnakeGameScene (Abstraction)
 ├── SnakeImpl (Agent)
 ├── FoodExpertImpl (Agent)
 ├── SnakeGameSceneRendererImpl (Worker_agent)
 ├── SnakeWindowImpl (Abstraction)
 └── SnakeGamePanelImpl (Abstraction + Swing Nature)

Each one knows exactly what it should know, and nothing more.

For instance, the FoodExpert agent handles food positions —
but knows nothing about the UI, keyboard, or rendering:

@Agent(Gender.EXPERT_COMPONENT)
public class FoodExpertImpl implements @Contracts FoodExpert {
    private @With_compat SnakeGameScene scene;

    public void positionFood() {
        Random random = new Random();
        ...
        food.setType(random.nextBoolean() ? FoodType.APPLE : FoodType.ORANGE);
        foodList.add(food);
    }
}

Meanwhile, the Worker Agent handles technical events and visual updates:

@Worker_agent
public class SnakeGameSceneRendererImpl implements @Contracts SnakeGameSceneRenderer {
    private @With_compat SnakeGameScene scene;

    public SnakeGameSceneRendererImpl(@With_compat SnakeGameScene scene) {
        this.scene = scene;
        EventQueue.invokeLater(this); // Executed in AWT thread
    }

    @Override
    public void run() {
        window = new SnakeWindowImpl(this); // creates and starts rendering
    }
}

🔁 3. Understanding the Flow of Life — The Snake Logic

The magic happens in SnakeImpl.
It shows how Clprolf models living behavior:
sliding, growing, interacting — without spaghetti code.

@Underst
@Long_action
protected void continueSliding() {
    if (this.lastSlidingType == SlidingType.STOPPED) return;

    SnakeLink newHeadLink = computeHeadLink(this.links.get(0));
    checkCollisionsForNewHead(newHeadLink);

    Food foodAtNewHeadPlace = this.scene.getFoodExpert().getFoodAt(newHeadLink.x, newHeadLink.y);
    updateBodyForSliding(foodAtNewHeadPlace != null, newHeadLink);
}

The @Underst annotation reminds that the logic involves reasoning —
not just a trivial mechanical step.
Each call represents an intention (“continue sliding”, “handle food”, “grow body”).
The structure itself communicates meaning.

🎨 4. Rendering Without Losing the Model

The UI never controls the game directly.
The window only refreshes every 20 ms —
and triggers the next logic step inside the paint cycle.

@Override
public void paintComponent(Graphics g) {
    super.paintComponent(g);
    drawSnakes(g);
    drawFood(g);

    // End of long actions — one physics step every few frames
    this.gameWindow.getReal().getScene().getSnake().endLongActions();
    this.gameWindow.getReal().getScene().getSnake_two().endLongActions();
}

So the render loop and game loop are naturally synchronized —
without timers, threads, or complicated scheduling.

🪢 5. Loose Coupling by Design — Not by Effort

With @With_compat, compatibility is both explicit and enforced:

public class SnakeImpl implements @Contracts Snake {
    protected @With_compat SnakeGameScene scene;
}

If a component tries to depend on something it shouldn’t —
Clprolf makes it visible, conceptually and syntactically.
You see the architecture as you read the code.

💡 6. What We Learn from This Example

You can build a complete game architecture without losing clarity.
Long actions and reasoning methods bring life-like modeling.
Workers act as true performers, keeping the domain clean.
Compatibility links replace DI frameworks and reflection.
The render loop stays synchronous, transparent, and elegant.

The result? A Snake that’s both fun and architecturally flawless.

🏁 Conclusion

Clprolf isn’t about writing fancy syntax.
It’s about making clarity a property of the codebase itself.

From clear code to clear game,
we didn’t just rewrite Snake — we understood it.

🧩 Full source code available here:

👉 GitHub — Clprolf Snake Game

Composite Pattern in Clprolf — Example with Files and Folders

Charles Koffler — Thu, 02 Oct 2025 19:29:32 +0000

The Composite pattern solves a classic problem:
👉 How to treat simple objects (“leaves”) and groups of objects (“composites”) in the same way?

In Traditional OOP

In OOP, we usually create:

a Component interface,
a Leaf class (e.g., a File) with no children,
a Composite class (e.g., a Folder) that contains other components.

It works, but the design often feels implicit: we must know by convention that File is a leaf and Folder is a composite.

In Clprolf

With Clprolf, roles and contracts make the Composite explicit:

FileSystemComponent is the contract for all components.
File is a Leaf: an abstraction with no extra methods.
Folder is a Composite: an abstraction with add() / remove() methods for direct children.
Implementations (FileImpl, FolderImpl) respect these roles with contracts.
A worker_agent launcher builds the tree and calls done().

The result: we can read the roles and hierarchy directly in the contracts — no ambiguity.

Example

public version_inh FileSystemComponent {
    void done();
}

public version_inh abstraction File nature FileSystemComponent { }

public  version_inh abstraction  Folder nature FileSystemComponent {
    void add(with_compat FileSystemComponent component);
    void remove(with_compat FileSystemComponent component);
}

Leaf

@Forced_pract_code
public abstraction FileImpl contracts File {
    private String name;

    public FileImpl(String name) { this.name = name; }

    public void done() { System.out.println("Leaf File: " + name); }
}

Composite

@Forced_pract_code
public abstraction FolderImpl contracts Folder {
    private String name;
    private List<FileSystemComponent> children = new ArrayList<>();

    public FolderImpl(String name) { this.name = name; }

    public void add(with_compat FileSystemComponent component) {
        children.add(component);
    }

    public void remove(with_compat FileSystemComponent component) {
        children.remove(component);
    }

    public void done() {
        System.out.println("Composite Folder: " + name);
        for (with_compat FileSystemComponent c : children) c.done();
    }
}

Launcher


public worker_agent CompositePatternLauncher {
    public static void main(String[] args) {
        FolderImpl root = new FolderImpl("Root");
        FolderImpl documents = new FolderImpl("Documents");
        FileImpl file1 = new FileImpl("File1.txt");

        documents.add(file1);
        root.add(documents);

        root.done();
    }
}

Output

Composite Folder: Root
Composite Folder: Documents
Leaf File: File1.txt

Why Clprolf Makes Composite Clear

Contracts show everything

File is a Leaf (no extra methods).
Folder is a Composite (can add/remove children).
Both are FileSystemComponent.

Each composite is simple
A Folder only knows its direct children.
The global hierarchy comes from recursion, not from extra complexity.
Roles prevent ambiguity
Implementations respect exactly the declared role — no mix-up between leaf and composite.

Conclusion

In OOP, the Composite is often taught as a trick with interfaces and polymorphism.
In Clprolf, it becomes obvious:

A Leaf is an abstraction without children.
A Composite is an abstraction with children of type FileSystemComponent.

👉 The pattern is no longer something to memorize, but something you can read directly in the contracts.

DEV Community: Charles Koffler

Introducing Flexibility Without Losing Structure in Clprolf

Introduction

Starting From Existing Code

A Flexible Entry Point

Structure Still Exists

Strict and Flexible Clprolf

Compatibility Between Both

Gradual Evolution

Working With Existing Libraries

Final Thought

🧱 Two Structural Principles behind Clprolf

Prerequisites

Foundational Principles of Clprolf

Relation to SRP

Relation to “Favor Composition Over Inheritance”

Closing

Preventing Architectural Drift in Object-Oriented Systems — A Structural Approach with Clprolf

A Structural Locking Approach

Locking the Nature at Creation Time

From Description to Commitment

Structural Discipline, Not Convention

Why This Matters

Getting Started with Clprolf: Structuring Responsibilities in OOP

📘 Getting Started with Clprolf

Prerequisites

Making Responsibilities Explicit

Foundational Principles of Clprolf

1️⃣ Declaring a Role

2️⃣ Start Flexible: indef_obj

3️⃣ Making Responsibilities Explicit

4️⃣ Structural Rules Are Enforced

6️⃣ What Clprolf Changes

7️⃣ Philosophy in One Sentence

Refactoring Your Classes with Clprolf and `indef_obj`

1️⃣ Starting from a Classic OOP Class

2️⃣ Using Clprolf Without Thinking About Roles

3️⃣ Applying SRP After Understanding the Code

4️⃣ Refactoring into Explicit Responsibilities

🎯 Business Responsibility → agent

⚙️ Technical Responsibilities → worker_agent

5️⃣ What Changed — and What Didn’t

❌ What did not change

✅ What did change

🧩 Conclusion

A Global Model of How Classes Relate to Each Other in Clprolf

1. Agent

Agent rules

2. Worker

Worker rules

3. Pure Abstraction

Pure Abstraction rules

4. System Abstraction

System Abstraction rules

5. Exceptions with @Forc_pract_code

6. Summary Table

7. Purpose of This Model

Separating Class Responsibilities with Clprolf

🌐 Why the term “declension”?

1) Two main declensions for two domains

🔹 agent

🔹 worker_agent

2) Synonyms to express different perspectives

For the agent declension:

For worker_agent:

3) Declensions work with your existing components

4) Domain consistency through inheritance rules

✔ Allowed

❌ Not allowed

5) Why this is useful in practice

6) Class declensions and SOLID

📌 How does this relate to DDD or Clean Architecture?

📌 Summary comparison

📌 Is Clprolf too rigid?

Examples with the Clprolf Java Framework (one-to-one with the Clprolf language declensions)

✅ Example 1 — A simple Service using a Repository

✅ Example 2 — A simple Repository (technical layer)

❌ Example 3 — Forbidden inheritance (Repository → Service)

✅ Example 4 — A simple real Agent (clean example)

✅ Example 5 - A Checkout service

2️⃣ Start Flexible: `indef_obj`

🎯 Business Responsibility → `agent`

⚙️ Technical Responsibilities → `worker_agent`

5. Exceptions with `@Forc_pract_code`

🔎 **Bonus — What SRP really means at the method level**

🧭 3. The Agent — `DirectoryExplorerImpl`