Programming paradigms — index

Paradigm literacy helps teams choose structure before frameworks: whether work is naturally object-shaped, function-shaped, or stream-shaped. Paradigms combine in production; the goal is deliberate composition, not…

Guide · Updated · Source

Cross-references: Software engineering body of knowledge § 1. Programming paradigms maps strengths; § 4. Principles (SOLID, composition) supports OO-heavy designs.

Paradigm relationships (mental model)

Paradigm relationships mental model

How teams choose object-, function-, or stream-shaped structure before frameworks, then compose paradigms deliberately in production.

  1. StartBegin with whether the problem is object-, function-, or stream-shaped.
  2. Core steps (see walkthrough below)Read the OOP, Functional, and Reactive guides linked below.
  3. OutcomeApply deliberate multi-paradigm layering rather than pursuing purity.

Teams often layer FP cores, OO boundaries, and reactive IO; arrows suggest common teaching lineage, not hard dependencies.

Which paradigm for which problem domain?

Problem domain Favor Why
Rich business rules with invariants OOP (+ DDD tactics) Identity, lifecycle, collaboration
Deterministic transforms / batch analytics FP Local reasoning; parallel maps
Real-time UI, sockets, market data Reactive Async composition; cancellation
Scripts, firmware, tight kernels Procedural Low ceremony; explicit control flow
Long-lived distributed services Multi-paradigm Split domain core from integration edges

Guides

Guide Focus See
OOP Encapsulation, polymorphism, composition vs inheritance, language notes, anti-patterns
Functional Purity, ADTs, FP/OOP matrix, practical functors/monads, ecosystems
Reactive Observables, operators, backpressure, Manifesto pillars, frameworks
Procedural (planned) Procedures, scripts, CLIs, embedded-style sequencing SOFTWARE-ENGINEERING.md §1
Multi-paradigm (planned) Layering styles and team conventions SOFTWARE-ENGINEERING.md §1

Keep project-specific engineering standards in docs/development/ and architecture decisions in docs/adr/, not in this file.