References: Meyer (1988) Object-Oriented Software Construction, Gamma et al. (1994) Design Patterns
Work in Progress: Concept is stable, adding practical examples and refinements.
Core idea
Object-oriented reasoning doesn’t have to live inside code. It can live in infrastructure.
Containers already behave like objects. This paper makes that mapping explicit.
The mapping
| OOP Concept | COP Equivalent |
|---|
| Class | Minimal image |
| Object | Container |
| Method | Routine |
| Attribute | Container state / volume |
| Constructor | Container initialization |
| Destructor | Container teardown |
| Inheritance | Image layering / composition |
| Polymorphism | Replaceable routines / images |
| Encapsulation | Container boundaries / interface |
| Decorator | Sidecar |
| Observer | External monitoring / sidecar |
| Strategy | Swappable container implementations |
Why this matters
Production workloads often consist of simple transformations, routing, and aggregation. Unix tools (awk, sed, tee) already embody functional programming principles. Inside containers, they gain object-like properties: encapsulation, identity, lifecycle control.
Interfaces are explicit
In COP, interfaces are paths, streams, and ports - not implicit method calls. This forces clarity at system boundaries. Behavior can be inspected, tested, and replaced without modifying internal logic.
Patterns emerge naturally
Factory: Image build pipelines and deployment controllers
Singleton: Enforced uniqueness in orchestration
Observer: Sidecars or external consumers of streams and metrics
Strategy: Swapping images behind a stable interface
Decorator: Sidecars attach to containers without modifying core logic
Sidecars are infrastructure-native decorators. A logging sidecar reads stdout, a metrics sidecar exposes counters, a policy sidecar enforces rules. The core container remains unchanged.
Minimal images as class discipline
Minimal images (like Chainguard) limit behavior, reduce attack surface, enforce reproducibility. They define exactly what routines are available - constraining object behavior in a verifiable way.
Polymorphism works operationally: replace one image with another that satisfies the same interface. Behavior changes without refactoring dependent components.
Testing
Each routine is tested independently:
cat test_input.log | ./metrics_routine.sh > result.log
diff result.log expected.log
Integration testing validates container composition - interface compatibility and data flow, not internal implementation.
The instruction boundary
COP defines the instruction as atomic. Commands like grep ERROR or pandoc -v are instructions. Behind them lies an enormous stack (syscalls, libraries, runtime), but COP intentionally does not model that. The container boundary is where reasoning stops.
Connection to other work
- Supply chain security: Signed, hardened minimal images are the “class discipline” COP describes
- UNIX philosophy paper: Same compositional thinking from different angle
- yml2mid: Similar text-as-structure approach applied to music