Introduction
Clprolf is both a language and an equivalent framework.
Its goal is to make certain object-oriented programming best practices explicit, without introducing heavy architecture or a steep learning curve.
Clprolf is based on a simple idea:
A class should clearly express its primary role.
The language helps to:
- separate business logic from technical code,
- limit architectural drift,
- make inheritance more coherent,
- improve system readability.
Clprolf remains fully object-oriented and close to Java.
I) The Two Fundamental Principles
Clprolf is built around two central principles.
1. A class is either business-oriented or technical
Every class belongs to one of the following worlds:
Business / Domain World
The class represents a business or conceptual responsibility.
Examples:
- order management,
- business logic,
- simulation,
- functional orchestration.
These classes are declared using:
agent
Technical World
The class performs a technical task:
- database access,
- networking,
- file handling,
- display,
- infrastructure.
These classes are declared using:
worker
2. Inheritance must preserve the domain
A class should only inherit from another class belonging to the same conceptual domain.
Otherwise:
composition should be used.
This principle prevents incoherent hierarchies and mixed responsibilities.
II) Class Types
Clprolf contains 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-oriented tasks,
- manages infrastructure,
- contains technical code.
Example:
public worker OrderRepository {
public void save(Order order) {
// database access
}
}
II.3) indef_obj
An 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 similar to classical OOP.
II.4) Primary Domain and Technical Code
Clprolf encourages moving as much technical code as possible from agent classes into worker classes.
However, an agent may contain a reasonable amount of technical code when doing so improves simplicity or readability.
An agent always has a primary domain representing its central responsibility.
Secondary responsibilities may exist as long as they remain consistent with that primary domain.
II.5) Freedom of Interpretation and Language Recommendations
The choice between agent and worker is left to the developer.
Some responsibilities may be interpreted differently depending on the adopted architectural vision.
For example, a connection may be represented:
- as an
agentif viewed as a functional abstraction; - or as a
workerif viewed as a purely technical mechanism.
However, in these cases, Clprolf recommends using an agent. For example, for a Connection class:
- an
agentto represent the connection, - and delegate technical code to one or more
workerclasses.
III) Inheritance
A class only inherits from another class within 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.
Inheritance can be forced using @Forc_inh above the class.
IV) Flexibility
Clprolf is flexible.
The developer therefore keeps their freedom:
- mixing responsibilities when necessary,
- progressive migration,
- compatibility with existing code,
- while always maintaining a primary domain.
The language mainly acts as:
a structural guide.
V) Interfaces
In Clprolf, interfaces are viewed as:
abstract forms of inheritance.
They therefore participate in the structural continuity of the system.
family_interf = primary family interface
trait_interf = trait, shared capability between families
compat_interf = unrestricted interface
In Clprolf, interfaces are not viewed as simple technical contracts.
Both extends and implements relationships are considered genuine conceptual inheritance relationships.
V.1) family_interf
An interface representing an abstract family.
Used for:
- polymorphism,
- decoupling,
- implementation variants.
Family interfaces also have 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);
}
Which may lead to:
public agent AnimalImpl implements Animal { (...) }
public agent HorseImpl extends AnimalImpl implements Horse { (...) }
V.2) trait_interf
An interface representing a shared capability across multiple family_interf.
Traits also use a target role:
agentworker
Business Example
public trait_interf agent Payable {
void pay();
}
Technical Example
public trait_interf worker Persistable {
void save();
}
V.3) compat_interf
A generic interface without a specific role.
Allows flexibility.
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 primary family_interf at a time, and the class role must match the interface target role.
Clprolf thus adopts a simple interface implementation model, similar to Java's single class inheritance.
Indeed, a family_interf is always the structural reflection of its implementation.
This enables systematic loose coupling.
trait_interf interfaces express a capability shared among multiple family_interf interfaces.
A trait_interf therefore represents a cross-cutting trait shared by several families.
Normally, a trait_interf may only be inherited by a family_interf, not directly by a class.
However, direct implementation of a trait_interf by a class remains tolerated in Clprolf, although discouraged.
Concrete Class
↓ implements
family_interf
↓ inherits from
trait_interf
A family_interf may inherit from multiple family_interf and/or trait_interf.
A trait_interf may inherit only from other trait_interf, since a trait remains a trait.
Interface inheritance may still be forced using @Forc_int_inh (or @Forc_inh when forcing inheritance across different target roles).
VI) General Architecture
Clprolf naturally encourages a simple architecture.
agent
↓ delegates to
worker
agent classes contain:
- business rules,
- decisions,
- orchestration.
worker classes perform:
- technical work,
- system access,
- machine operations.
An agent delegates technical code to one or more worker classes.
A worker serves the agent.
VII) Clprolf Framework
Clprolf can also be used as a framework within an existing language such as Java.
In that case, 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 Example
@Agent
@Family_interf
public interface PaymentService {
}
Technical Example
@Worker
@Family_interf
public interface DatabaseStorage {
}
VII.3) Trait Interfaces
Trait interfaces use:
@Trait_interf
along 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) Purpose of the Language
Clprolf does not aim to replace classical OOP.
It aims to make certain important distinctions explicit:
- business vs technical,
- coherent inheritance vs composition,
- primary responsibility of a class.
IX) Summary
Clprolf introduces 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.
