Introduction
Clprolf Minimalist is a simplified version of the Clprolf language.
Its goal is to make certain object-oriented programming best practices explicit, without introducing heavy architecture or a steep learning curve.
Clprolf Minimalist is based on one simple idea:
A class must clearly express its main role.
The language therefore helps to:
- separate business logic from technical code,
- limit architectural drift,
- make inheritance more coherent,
- improve system readability.
Clprolf Minimalist remains fully object-oriented and close to Java.
I) The Two Fundamental Principles
Clprolf Minimalist is based on two central principles.
1. A class is either business-oriented or technical
Each class belongs to one of the following two worlds:
Business / domain world
The class represents a business or conceptual responsibility.
Examples:
- order management,
- business logic,
- simulation,
- functional orchestration.
These classes are declared with:
agent
Technical world
The class performs technical work:
- database access,
- networking,
- files,
- rendering,
- infrastructure.
These classes are declared with:
worker
2. Inheritance must preserve the domain
A class should inherit only from a class belonging to the same conceptual domain.
Otherwise:
composition should be used.
This principle prevents incoherent hierarchies and mixed responsibilities.
II) Class Types
Clprolf Minimalist has only three class types.
II.1) agent
Represents a business or conceptual class.
An agent:
- contains business logic,
- orchestrates processes,
- makes decisions,
- avoids heavy technical code.
Example:
public agent OrderProcessor {
private OrderRepository repository;
public void process(Order order) {
if(order.total() <= 0) {
throw Error;
}
repository.save(order);
}
}
II.2) worker
Represents a technical class.
A worker:
- performs machine tasks,
- manages infrastructure,
- contains technical code.
Example:
public worker OrderRepository {
public void save(Order order) {
// database access
}
}
II.3) indef_obj
Object without a defined role.
Used:
- during prototyping,
- during refactoring,
- when the role is not yet clear.
Example:
public indef_obj TemporaryManager {
}
indef_obj enables a flexible approach close to classical OOP.
II.4) Main Domain and Technical Code
Clprolf encourages moving as much technical code as possible from agent classes into worker classes.
However, an agent may still contain a reasonable amount of technical code when it improves the simplicity or readability of the system.
An agent always has a main domain representing its central responsibility.
Secondary responsibilities may exist as long as they remain coherent with this main domain.
II.5) Freedom of Interpretation
The choice between agent and worker is left to the developer.
Some responsibilities may be interpreted differently depending on the chosen architectural vision.
For example, a connection may be represented:
- as an
agent, if it is viewed as a functional abstraction; - or as a
worker, if it is considered a purely technical mechanism.
If one wishes to clearly separate the functional logic related to the connection from its technical implementation, one may use:
- an
agentto represent the connection, - and delegate the technical code to one or more
workerclasses.
III) Inheritance
Clprolf Minimalist greatly simplifies inheritance.
The nature keyword disappears.
The rule becomes implicit:
a class inherits only from a class belonging to the same domain.
Valid example
public agent Animal {
}
public agent Dog extends Animal {
}
Discouraged example
public worker DatabaseConnection {
}
public agent Dog extends DatabaseConnection {
}
Here, the domains are incompatible.
Composition should be used instead.
Class inheritance forcing remains possible with @Forc_inh above the class.
IV) Flexible Mode
Clprolf Minimalist operates only in:
flexible mode
The developer therefore keeps their freedom:
- mixing remains possible if necessary,
- progressive migration is allowed,
- compatibility with existing code is preserved,
- but there is always a main domain.
The language mainly acts as:
a structural guide.
V) Interfaces
In Clprolf Minimalist, interfaces are viewed as:
abstract forms of inheritance.
They therefore participate in the structural continuity of the system.
family_interf = primary interface of a family
trait_interf = trait, shared capability between families
compat_interf = unrestricted interface
In Clprolf, interfaces are not viewed as simple technical contracts.
The extends and implements relationships are considered genuine forms of conceptual inheritance, hence the term “family”.
V.1) family_interf
Interface representing an abstract family.
Used for:
- polymorphism,
- decoupling,
- implementation variants.
Family interfaces also possess a target role:
agent- or
worker
Example
public family_interf agent Animal {
void eat(int quantity);
}
The hierarchy of family_interf interfaces naturally reflects the hierarchy of concrete classes.
public family_interf agent Horse extends Animal {
void jump(int height);
}
And will naturally lead to:
public agent AnimalImpl implements Animal { (...) }
public agent HorseImpl extends AnimalImpl implements Horse { (...) }
V.2) trait_interf
Interface representing a shared functionality between several family_interf.
Traits use a target role, just like family_interf:
agentworker
Business-side example
public trait_interf agent Payable {
void pay();
}
Technical-side example
public trait_interf worker Persistable {
void save();
}
V.3) compat_interf
Generic interface without any particular role.
Allows the system to remain flexible.
Example
public compat_interf ExternalApi {
}
V.4) Interface Usage
In Clprolf, family_interf interfaces are the equivalent of pure abstract classes.
They are intended to be implemented by one or more future Clprolf classes.
They therefore possess a target role (agent or worker).
A class may implement only one main family_interf at a time, and the role of the class must match the target role of the interface.
Clprolf therefore uses simple interface implementation, in the same way that Java uses simple class inheritance.
Indeed, a family_interf is always the structural reflection of its implementation.
This notably enables systematic loose coupling.
trait_interf interfaces express a shared functionality between several family_interf interfaces.
A trait_interf therefore represents a transversal trait shared across multiple families.
Normally, a trait_interf may only be inherited by a family_interf interface, and not directly by a class.
However, in Clprolf Minimalist, direct implementation of a trait_interf by a class remains tolerated, although discouraged.
Concrete class
↓ implements
family_interf
↓ inherits from
trait_interf
Note: a family_interf interface may inherit from multiple family_interf or trait_interf interfaces.
A trait_interf interface may inherit only from other trait_interf interfaces, because a trait remains a trait.
Interface inheritance forcing remains possible with @Forc_int_inh above the interface (or @Forc_inh to force inheritance between different target roles).
VI) General Architecture
Clprolf Minimalist naturally encourages a simple architecture.
agent
↓ delegates to
worker
agents contain:
- business rules,
- decisions,
- orchestration.
workers perform:
- technical work,
- system access,
- machine operations.
An agent delegates technical code to one or more worker classes.
It may still execute technical operations itself, but by calling methods from a worker.
The worker is at the service of the agent.
VII) Clprolf Framework
Clprolf may also be used as a framework inside an existing language such as Java.
In that case, the keywords are replaced with annotations.
VII.1) Classes
Agent
@Agent
public class OrderProcessor {
}
Worker
@Worker
public class OrderRepository {
}
Indefinite Object
@Indef_obj
public class TemporaryManager {
}
VII.2) Family Interfaces
Family interfaces use two annotations:
- a role annotation,
- plus
@Family_interf.
Business-side example
@Agent
@Family_interf
public interface PaymentService {
}
Technical-side example
@Worker
@Family_interf
public interface DatabaseStorage {
}
VII.3) Trait Interfaces
Trait interfaces use:
@Trait_interf
with a target role.
Business example
@Agent
@Trait_interf
public interface Payable {
}
Technical example
@Worker
@Trait_interf
public interface Persistable {
}
VII.4) Free Compatibility
@Compat_interf
public interface ExternalApi {
}
VIII) What Has Been Removed
In order to drastically reduce complexity:
modelinformationabstractionsimu_real_objcomp_as_worker- renaming
worker_agenttoworker
- renaming
version_inhtofamily_interf
- renaming
capacity_inhtotrait_interf
naturecontractsunderstwith_compat- genders
- synonyms
- interface advices replaced with a target role
- advanced concurrency/parallelism mechanisms
have been removed from the minimalist version.
IX) Goal of the Language
Clprolf Minimalist does not aim to replace classical OOP.
It aims to make certain important distinctions explicit:
- business vs technical,
- coherent inheritance vs composition,
- the primary responsibility of a class.
X) Summary
Clprolf Minimalist adds very few concepts.
Classes
agent
worker
indef_obj
Interfaces
family_interf
trait_interf
compat_interf
Two Fundamental Rules
1. Separate business and technical concerns.
2. Inherit only within the same domain.