How the AI Detects the Paradigm
Most codebases are not purely OOP or purely functional â they blend both. But every codebase has a dominant paradigm that shapes: how data is modeled (classes with methods vs plain objects with functions), how behavior is organized (inheritance hierarchies vs function composition), and how state is managed (mutable instance properties vs immutable data transformations). The AI must detect this dominant paradigm to generate code that fits.
OOP signals: class definitions with methods, extends keywords for inheritance, this keyword usage, private/protected access modifiers, constructor methods, interface implementations (implements keyword). Functional signals: standalone exported functions, const with arrow functions, .map/.filter/.reduce chains, spread operators for immutable updates, pipe/compose utilities, no class definitions. AI rule: 'Scan the existing code files. If classes dominate: generate OOP. If standalone functions dominate: generate functional. Match the codebase, not the paradigm preference.'
Language-specific defaults: Java and C# are OOP-dominant. Haskell and Elixir are functional-dominant. TypeScript, Python, Rust, and Go support both but have community conventions. TypeScript React: functional (hooks, functional components). TypeScript NestJS: OOP (decorators, classes, dependency injection). Python Django: OOP (class-based views, model classes). Python FastAPI: mixed (functions for routes, classes for models). The framework often determines the paradigm more than the language.
OOP AI Rules: Classes, Inheritance, and Patterns
When the codebase is OOP: the AI should generate classes with methods, use inheritance where the existing code uses it, follow SOLID principles, and use the project's dependency injection pattern. AI rule: 'OOP codebase: new features are classes. Services, repositories, controllers are classes with constructor injection. Use interfaces for abstractions. Prefer composition over inheritance (inject dependencies, do not create deep inheritance chains).'
Common OOP patterns the AI should recognize and follow: Repository pattern (class UserRepository with find, create, update, delete methods), Service pattern (class UserService with business logic methods that call repositories), Factory pattern (static create methods or factory classes), Observer pattern (event emitters with subscribe/unsubscribe). AI rule: 'Identify the existing architectural patterns. New code should follow the same patterns. If UserRepository exists, create OrderRepository with the same interface.'
OOP pitfalls the AI should avoid: God classes (one class that does everything), deep inheritance chains (more than 2-3 levels), mutable shared state (singleton classes with mutable properties), tight coupling (classes that directly instantiate their dependencies instead of accepting them via constructor). AI rule: 'Small classes with single responsibilities. Constructor injection for dependencies. Interfaces for abstractions. No class should exceed 200 lines.'
Even in OOP codebases: prefer composition (injecting dependencies via constructor) over inheritance (extending base classes). Deep inheritance chains make AI code generation harder because: the AI must understand the full chain to know what methods are available, overridden behavior creates surprises, and changes to a base class cascade unpredictably. Flat hierarchies with injected dependencies are easier for both humans and AI to reason about.
Functional AI Rules: Pure Functions and Composition
When the codebase is functional: the AI should generate standalone functions, use composition over inheritance, prefer immutable data (spread operators, Object.freeze, readonly types), and avoid side effects in business logic. AI rule: 'Functional codebase: new features are exported functions. Data transformations are pure (same input = same output). Side effects (database calls, API requests) are isolated at the edges. Business logic is pure functions in the middle.'
Common functional patterns: pipeline/compose (data flows through a series of transformations), map/filter/reduce for collection processing, pattern matching (switch/case or discriminated unions in TypeScript), Either/Result types for error handling (return errors instead of throwing), currying and partial application for configurable functions. AI rule: 'Use the project's existing functional patterns. If the codebase uses Result types: return Results, do not throw. If it uses pipe(): compose new functions into the pipeline.'
Functional pitfalls the AI should avoid: impure functions disguised as pure (functions that read global state or call APIs without indication), excessive abstraction (point-free style that is hard to read), nested ternaries instead of clear if/else, recreating OOP patterns with closures (a closure with internal state is just a class with extra steps). AI rule: 'Readable first, pure second. A slightly impure function that is easy to understand is better than a purely functional abstraction that takes 5 minutes to parse.'
The biggest functional programming mistake AI makes: generating point-free style or deeply nested compose chains that are technically elegant but hard to read. A function that mutates a local variable and returns the result is easier to understand than a chain of 5 composed pure functions. The rule: pure functions where practical, readable code always. If a team member cannot understand the function in 30 seconds, it is too abstract.
Mixed-Paradigm Codebases
Most real-world codebases mix paradigms by layer: domain models may be classes (OOP), data transformations may be functions (functional), React components are functional, NestJS controllers are classes, utility modules are functions, API clients may be classes. AI rule: 'Identify the paradigm per layer. Match each layer's convention independently. A project can have OOP services and functional utilities â generate the right paradigm for the right layer.'
TypeScript is the most common mixed-paradigm language in 2026. A typical TypeScript project: functional React components (hooks, no classes), class-based services (if using NestJS or similar), functional utility modules, interface-based type definitions (which work with both paradigms), and mixed data modeling (class instances for ORM entities, plain objects for DTOs). The AI should: not force one paradigm across all layers.
The decision framework: if adding a new module that has similar existing modules, match their paradigm. If adding a new module type (no existing example): prefer functional for stateless logic (utilities, transformations, route handlers) and classes for stateful entities (database connections, WebSocket managers, cache clients). AI rule: 'Stateless = functions. Stateful = classes. When in doubt: functions are simpler and testable.'
A Next.js + NestJS full-stack project uses functional programming in the frontend (React components, hooks, utility functions) and OOP in the backend (NestJS controllers, services, repositories). The AI must not apply the frontend paradigm to the backend or vice versa. Scan the files in the directory you are working in â that layer's paradigm is what matters, not the overall project label.
Paradigm Comparison Summary
Summary of OOP vs functional programming AI rules across languages and frameworks.
- Detection: scan existing code for classes (OOP) vs standalone functions (functional)
- OOP: classes, inheritance, SOLID principles, dependency injection, Repository/Service patterns
- Functional: pure functions, immutability, composition, map/filter/reduce, Result types
- Framework determines paradigm: NestJS = OOP. React hooks = functional. FastAPI = mixed
- Mixed codebases: match the paradigm per layer. Services may be OOP, utilities functional
- Stateless logic = functions. Stateful entities = classes. When in doubt: prefer functions
- OOP pitfalls: God classes, deep inheritance. Functional pitfalls: excessive abstraction
- 2026 trend: functional-first with OOP for framework-mandated patterns (NestJS, TypeORM)