DEV Community

Charles Koffler
Charles Koffler

Posted on • Edited on

Clprolf Docs #1 — Declensions Explained

#architecture #designpatterns #tutorial

📝 This article is part of the official Clprolf documentation series (1/6).
Clprolf is a new programming language and framework that adds clarity to OOP by enforcing roles, responsibilities, and clean design.

Clprolf is a language and framework that helps you design objects with a single, explicit responsibility.
By assigning each class a role (also called its declension), you ensure compliance with the Single Responsibility Principle (SRP).
Objects become components, and this clarity remains intact even with inheritance.

What Is a Declension?

A declension expresses the nature of a class — its fundamental role in the system.
Clprolf defines only a few basic roles, which keeps design unambiguous and intuitive.

The five available declensions are:

  1. agent
    Synonyms: abstraction, simu_real_obj.

  2. worker_agent
    Synonyms: comp_as_worker.

  3. model
    (no synonyms).

  4. information
    (no synonyms).

  5. indef_obj
    A flexible object without explicit role, behaving like a traditional OO class.

Synonyms and Aspects

Each declension keeps only a minimal set of synonyms, and every synonym reflects a specific aspect:

  • Agent declension → agent (agent aspect), abstraction (object aspect), simu_real_obj (simulation aspect)
  • Worker_agent declension → worker_agent (agent aspect), comp_as_worker (simulation aspect)
  • Model declension → model
  • Information declension → information
  • Indef_obj declension → indef_obj

This structure makes the system both easy to memorize and easy to teach.
Synonyms are no longer arbitrary alternatives but clearly justified by the perspective they express.

Business-Like Objects

These objects represent real-world abstractions or domain concepts.

  • agent: the active actor.

    • agent emphasizes action.
    • simu_real_obj emphasizes simulation.
    • abstraction emphasizes conceptual encapsulation (e.g., a Connection, a Socket).

  • abstraction: for abstract concepts and system elements (connections, sockets, system utilities).

  • simu_real_obj: a micro-simulation of a real-world entity.
    Example: a Giraffe class with states and behaviors simulating how a giraffe acts.

  • model: a passive entity with no behavior — just attributes.
    Example: a Customer with fields but no methods.

Technical Objects

These objects handle purely computational or support tasks.
Here, the computer itself is seen as the actor.

  • worker_agent: the computer as a worker executing algorithms.
    Synonyms: comp_as_worker.

  • information: a coherent data container, used by workers in algorithms.
    ⚠️ Unlike model, it does not represent a real-world entity, only technical data.

Examples: system utilities, DAOs, repositories, low-level services, or MVC view components.

Declensions and Genders

Declensions can be refined with genders (optional sub-roles).
They may also have synonyms:

  • @Expert_component = @Human_expert
  • @Active_agent (no synonym)
  • @Static = @Expert_component_static = @Human_expert_static
  • @Static for worker_agent (no synonym)

⚠️ Genders apply only to agents, except @Static, which may also apply to worker_agent.

Interrelationships Between Declensions

  • Agents and Workers
    Every agent can also act as a worker (computers execute agents as workers).
    But explicit workers should be minimized for clarity.

  • Models and Information
    A model can be represented as information (stored as data),
    but information should not replace a model.

  • Unidirectional Substitutions

    • Agent → Worker ✅
    • Worker → Agent ❌
    • Model → Information ✅
    • Information → Model ❌

These reversals usually reveal a design flaw or a deliberate reinterpretation.

Interfaces and Declensions

Interfaces also have declensions:

  • compat_interf_version = version_inh
  • compat_interf_capacity = capacity_inh
  • compat_interf (no synonym)

Declensions on interfaces specify which classes are allowed to implement them.

Capacity interfaces can also have a gender called Advice:

  • @For_agent_like
  • @For_worker_like

Inheritance Consistency

Clprolf enforces that inheritance stays role-consistent:

  • Business and technical objects cannot be mixed in the same hierarchy.
  • Synonyms of a declension are accepted.
  • Exceptions may be forced with @Forced_inh.

Using Declensions

In pure Clprolf, the declension replaces the class keyword.
In the framework, it appears as an annotation above the class.

Example:

@Agent
public class Animal { ... }
Enter fullscreen mode Exit fullscreen mode

Algorithm for Choosing a Declension

Every class must declare a role.

Step 1 – Does the class have methods?

  • Yes → it is active → choose @Agent or @Worker_agent.
  • No → it is passive → use @Model (entity) or @Information (technical container).

Step 2 – Is the responsibility business-related or technical?

  • Business logic or expert knowledge → @Agent.
  • Technical or support layer → @Worker_agent.

Example: System Class in Java

At first sight: @Worker_agent (low-level, technical).

But Clprolf favors @Agent whenever possible.
System could also be seen as:

  • @Abstraction — since “the system” is a conceptual entity.
  • @Agent(Gender.EXPERT_COMPONENT) — as an expert component representing the environment.

Summary

  • Declensions make objects into components with explicit roles.
  • Roles clarify responsibilities, improve readability, and ensure inheritance coherence.
  • Synonyms keep flexibility while preserving consistency.

Result: a simpler, more maintainable system, where every object is clearly positioned.

Notice

If the class already fits one of the well-known architectural categories, you can directly assign a matching role:

  • A service → @Agent
  • A helper → @Agent or @Worker_agent (often with Gender.STATIC)
  • A DAO or repository → @Worker_agent
  • A controller → @Agent

Top comments (0)