# The lex records whose category is core-modular-design

This index as JSON: https://banes-lab.com/json/api/facets/lex/category/core-modular-design

## Entries

- [Anemic Encapsulation](https://banes-lab.com/records/lex/anemic-encapsulation.md): Wrapping data in a class that exposes it through trivial getters and setters, leaving its invariants unprotected.
- [Blob Class](https://banes-lab.com/records/lex/blob-class.md): A single class that absorbs many unrelated responsibilities, growing large and hard to change safely.
- [Centralized Runtime Control](https://banes-lab.com/records/lex/centralized-runtime-control.md): Concentrating runtime control in one place so otherwise-independent modules cannot act without it.
- [Context-Specific Coupling](https://banes-lab.com/records/lex/context-specific-coupling.md): Baking one caller's specific assumptions into a component, preventing its reuse elsewhere.
- [Copy-Paste Programming](https://banes-lab.com/records/lex/copy-paste-programming.md): Duplicating code by copying and pasting instead of extracting a shared abstraction.
- [Cross-Cutting Leakage](https://banes-lab.com/records/lex/cross-cutting-leakage.md): Letting a concern such as logging or security bleed into unrelated modules throughout the code.
- [Deep Inheritance Hierarchy](https://banes-lab.com/records/lex/deep-inheritance-hierarchy.md): Stacking many layers of subclassing, so behavior is scattered and fragile to change.
- [Exposed Internals](https://banes-lab.com/records/lex/exposed-internals.md): Making a module's internal fields and workings public, so callers depend on details that should be hidden.
- [Implementation-Specific Contracts](https://banes-lab.com/records/lex/implementation-specific-contracts.md): Defining an interface around one implementation's quirks, so no alternative can satisfy it.
- [Leaky Abstraction](https://banes-lab.com/records/lex/leaky-abstraction.md): An abstraction that forces callers to understand its underlying implementation to use it correctly.
- [Mixed Layers](https://banes-lab.com/records/lex/mixed-layers.md): Interleaving different architectural layers' logic in one place instead of keeping each concern separate.
- [Monolithic Procedures](https://banes-lab.com/records/lex/monolithic-procedures.md): Writing large all-in-one procedures that cannot be recombined from smaller, independent parts.
- [Shared Runtime Dependency](https://banes-lab.com/records/lex/shared-runtime-dependency.md): Coupling supposedly-independent modules through a shared runtime component they all depend on.
- [Tight Coupling](https://banes-lab.com/records/lex/tight-coupling.md): Binding components so closely that a change in one forces changes in the others.
- [Bounded Context Ownership](https://banes-lab.com/records/lex/bounded-context-ownership.md): The ability for a team or module to own and control one bounded part of the system.
- [Change Isolation](https://banes-lab.com/records/lex/change-isolation.md): The ability to confine the impact of a change behind a boundary so callers are unaffected.
- [Independent Testing](https://banes-lab.com/records/lex/independent-testing.md): The ability to test a component in isolation without standing up its collaborators.
- [Internal Refactoring](https://banes-lab.com/records/lex/internal-refactoring.md): The ability to rework a module's internals freely as long as its interface stays stable.
- [Invariant Protection](https://banes-lab.com/records/lex/invariant-protection.md): The ability to guarantee an object's rules always hold by controlling all access to its state.
- [Product Lines](https://banes-lab.com/records/lex/product-lines.md): The ability to build a family of related products from shared, reusable components.
- [Shared Libraries](https://banes-lab.com/records/lex/shared-libraries.md): The ability to factor common functionality into libraries reused across projects.
- [Strategy Swap](https://banes-lab.com/records/lex/strategy-swap.md): The ability to replace one interchangeable algorithm or implementation with another.
- [Test Isolation](https://banes-lab.com/records/lex/test-isolation.md): The ability to exercise a unit under test without its dependencies interfering.
- [Vendor Swap](https://banes-lab.com/records/lex/vendor-swap.md): The ability to replace one vendor's implementation with another behind a stable interface.
- [Delegation](https://banes-lab.com/records/lex/delegation.md): Forwarding work to a contained collaborator object rather than inheriting the behavior.
- [Deep Optimization](https://banes-lab.com/records/lex/deep-optimization.md): The practice of optimizing heavily against a specific implementation's traits, which ties code to it.
- [YAGNI](https://banes-lab.com/records/lex/yagni.md): You Aren't Gonna Need It: build only what current requirements demand and defer speculative generality.
- [Canonical Source](https://banes-lab.com/records/lex/canonical-source.md): The requirement that each piece of knowledge have one authoritative definition rather than copies.
- [Contract Compatibility](https://banes-lab.com/records/lex/contract-compatibility.md): The requirement that alternative implementations honor the same interface contract.
- [Explicit Interfaces](https://banes-lab.com/records/lex/explicit-interfaces.md): The requirement that a module interact only through declared interfaces, not its hidden internals.
- [Interface Conformance](https://banes-lab.com/records/lex/interface-conformance.md): The requirement that each implementation fully conform to the shared interface's contract.
- [Interface Definition](https://banes-lab.com/records/lex/interface-definition.md): The requirement that an abstraction expose a defined interface separate from its implementation.
- [Stable Semantics](https://banes-lab.com/records/lex/stable-semantics.md): The requirement that an abstraction's meaning stay consistent even as its implementations change.
- [Coordination Cost](https://banes-lab.com/records/lex/coordination-cost.md): The degree of extra coordination required when components are made fully independent.
- [Excessive Fragmentation](https://banes-lab.com/records/lex/excessive-fragmentation.md): The degree to which splitting responsibilities too finely scatters logic across many small units.
- [Locality of Behavior](https://banes-lab.com/records/lex/locality-of-behavior.md): The degree to which keeping related behavior together can conflict with removing all duplication.
- [Over-Generalization](https://banes-lab.com/records/lex/over-generalization.md): The degree to which making code reusable for every case adds abstraction that harms clarity.
- [Over-Layering](https://banes-lab.com/records/lex/over-layering.md): The degree to which adding separating layers introduces indirection that outweighs the separation gained.
- [Over-Specialization](https://banes-lab.com/records/lex/over-specialization.md): The degree to which pursuing tight cohesion can narrow a unit's purpose too far to reuse.
- [Performance Overhead](https://banes-lab.com/records/lex/performance-overhead.md): The degree of runtime cost added by composing behavior from many small, indirected parts.
- [Simplicity for Trivial Reuse](https://banes-lab.com/records/lex/simplicity-for-trivial-reuse.md): The degree to which composition adds wiring that inheritance would make simpler for trivial reuse.
- [Specialized Optimization](https://banes-lab.com/records/lex/specialized-optimization.md): The degree to which optimizing for one implementation undermines the ability to swap implementations.