What Is Composition? - Learning Module

Loading content...

0/246

Composition as Assembly

The Assembly Line of Software

In 1913, Henry Ford revolutionized manufacturing by introducing the assembly line. Rather than skilled craftsmen building entire cars from start to finish, specialized workers would each contribute a specific component—one installs wheels, another attaches the engine, another connects the electrical system. Each component was designed to be interchangeable: any engine of the right model would fit any chassis of the right model.

This wasn't just an efficiency improvement—it was a paradigm shift in how complex products could be built. Components could be manufactured in parallel, improved independently, and substituted without rebuilding the entire system. Quality could be controlled at each step. Defects could be traced to specific components.

Software composition embodies the same paradigm. When we think of composition as assembly, we gain powerful design insights about interchangeability, standardization, modular improvement, and the economics of software construction.

What You Will Learn

By the end of this page, you will understand composition through the assembly metaphor—how interchangeable parts, standardized interfaces, and modular construction principles apply to software design. You'll learn how this perspective drives decisions about component boundaries, interface design, and system evolution.

The Assembly Metaphor for Software Composition

The assembly metaphor views software construction as the process of combining prefabricated components into working systems. Just as manufacturers assemble products from standardized parts, software engineers assemble applications from well-defined software components.

Let's map the key concepts:

Manufacturing to Software Mapping
Manufacturing Concept	Software Equivalent	Example
Assembly line	Build/composition process	Application bootstrap that wires components together
Standardized part	Component with well-defined interface	`PaymentGateway` interface with `charge()` method
Part supplier	Library, service, or module	Third-party payment SDK or internal auth module
Part specification	Interface/contract definition	TypeScript interface or API contract
Quality control	Testing at component boundaries	Unit tests for components, integration tests for assemblies
Part substitution	Swapping implementations	Replacing `StripeGateway` with `PayPalGateway`
Product variation	Configuration-driven assembly	Building different editions with different feature sets

The power of this metaphor lies in how it shapes our thinking about component design. When you view your classes and modules as "parts" that will be assembled, you naturally gravitate toward:

Clear interfaces that define how parts connect
Minimal dependencies that don't require specific other parts
Self-contained functionality that works wherever the part is used
Predictable behavior that doesn't surprise assemblers

These are exactly the properties that make software maintainable and evolvable.

Think Like a Part Manufacturer

When designing a component, imagine you're manufacturing a part that will be used by unknown assemblers in unknown products. You can't know all the contexts where your part will be used. This mindset naturally leads to better interfaces, fewer assumptions, and more reusable components.

Interchangeability: The Foundation of Flexible Systems

In manufacturing, interchangeability means that any unit of a given part can be substituted for any other unit of that same part. A replacement alternator will fit any car of the same model; any standardized screw of a given size will fit any matching nut.

In software, interchangeability means that any implementation of an interface can substitute for any other implementation of that interface without breaking the system. This is the practical foundation of flexible, evolvable software.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
// Interchangeability through interface contracts
 
// The interface defines the "socket" - what any part must provide
interface DocumentStorage {
    save(id: string, content: string): Promise<void>;
    load(id: string): Promise<string | null>;
    delete(id: string): Promise<boolean>;
    exists(id: string): Promise<boolean>;
}
 
// Multiple interchangeable implementations (parts that fit the socket)
 
class FileSystemStorage implements DocumentStorage {
    constructor(private basePath: string) {}
    
    async save(id: string, content: string): Promise<void> {
        await fs.writeFile(path.join(this.basePath, id), content);
    }
    async load(id: string): Promise<string | null> {
        try {
            return await fs.readFile(path.join(this.basePath, id), 'utf-8');
        } catch { return null; }
    }
    async delete(id: string): Promise<boolean> {
        try {
            await fs.unlink(path.join(this.basePath, id));
            return true;
        } catch { return false; }
    }
    async exists(id: string): Promise<boolean> {
        return await fs.access(path.join(this.basePath, id))
            .then(() => true).catch(() => false);
    }
}
 
class S3Storage implements DocumentStorage {
    constructor(private bucket: string, private client: S3Client) {}
    
    async save(id: string, content: string): Promise<void> {
        await this.client.putObject({ Bucket: this.bucket, Key: id, Body: content });
    }
    async load(id: string): Promise<string | null> {
        try {
            const result = await this.client.getObject({ Bucket: this.bucket, Key: id });
            return await result.Body?.transformToString() ?? null;
        } catch { return null; }
    }
    // ... delete, exists implementations
}
 
class InMemoryStorage implements DocumentStorage {
    private documents = new Map<string, string>();
    
    async save(id: string, content: string): Promise<void> {
        this.documents.set(id, content);
    }
    async load(id: string): Promise<string | null> {
        return this.documents.get(id) ?? null;
    }
    async delete(id: string): Promise<boolean> {
        return this.documents.delete(id);
    }
    async exists(id: string): Promise<boolean> {
        return this.documents.has(id);
    }
}
 
// The consumer doesn't know or care which implementation is used
class DocumentService {
    constructor(private storage: DocumentStorage) {}
    
    async saveDocument(doc: Document): Promise<void> {
        await this.storage.save(doc.id, JSON.stringify(doc));
    }
    
    async getDocument(id: string): Promise<Document | null> {
        const content = await this.storage.load(id);
        return content ? JSON.parse(content) : null;
    }
}
 
// Assembly with interchangeable parts
const devService = new DocumentService(new InMemoryStorage());
const testService = new DocumentService(new FileSystemStorage('./test-docs'));
const prodService = new DocumentService(new S3Storage('prod-bucket', s3Client));

The benefits of interchangeability:

Why Interchangeability Matters

•Environment-specific assembly: Use in-memory storage in development, file system in testing, cloud storage in production—same application code.
•Testing flexibility: Substitute fast, controllable test doubles for slow, external components during testing.
•Graceful evolution: Replace implementations with better versions without modifying consumers.
•Vendor independence: Switch from AWS to GCP, or Stripe to PayPal, by swapping implementations.
•Feature toggling: Assemble with different implementations based on feature flags or A/B tests.

Standardized Connectors: Interfaces as Attachment Points

Interchangeability in manufacturing depends on standardized connectors—the mounting points, electrical plugs, and mechanical interfaces that allow parts to attach to assemblies. A USB-C cable works with any USB-C port because both adhere to the USB-C standard.

In software, interfaces serve as standardized connectors. They define exactly how components attach to the rest of the system—what methods are available, what parameters are expected, what return values are promised. When interfaces are well-designed, they become reliable connection standards that many implementations can satisfy.

Principles of good connector (interface) design:

Interface Design Principles
Principle	Description	Violation Example
Minimal surface	Include only what consumers need, not what implementations happen to offer	Including `getInternalState()` because one implementation has it
Domain-focused vocabulary	Use terms from the problem domain, not implementation technologies	`saveToPostgres()` instead of generic `save()`
Stable over time	Design for contracts that won't need frequent changes	Method signatures that change with every version
Complete for purpose	Include enough methods to fully accomplish the intended task	Storage interface without `delete()` method
Unsurprising behavior	Methods do what their names suggest, consistently	`load()` that sometimes caches and sometimes doesn't

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// Good interface design: Clear, minimal, domain-focused connectors
 
// Good: Minimal, focused interface
interface EmailSender {
    send(to: string, subject: string, body: string): Promise<SendResult>;
}
 
// Bad: Leaky abstraction exposing implementation details
interface BadEmailSender {
    send(to: string, subject: string, body: string): Promise<SendResult>;
    getSmtpConnection(): SmtpConnection;  // Leaks SMTP implementation
    setAwsSesCredentials(creds: AWSCredentials): void;  // Leaks AWS implementation
    retryCount: number;  // Implementation detail
}
 
// Good: Role-based interface for specific consumer needs
interface OrderNotifier {
    notifyOrderConfirmed(order: Order): Promise<void>;
    notifyOrderShipped(order: Order, trackingNumber: string): Promise<void>;
    notifyOrderDelivered(order: Order): Promise<void>;
}
 
// Bad: Fat interface doing too many different things
interface BadNotificationSystem {
    sendEmail(to: string, subject: string, body: string): Promise<void>;
    sendSms(phone: string, message: string): Promise<void>;
    sendPushNotification(deviceId: string, payload: any): Promise<void>;
    notifyOrderConfirmed(order: Order): Promise<void>;
    notifyPasswordReset(user: User, resetLink: string): Promise<void>;
    broadcastMaintenanceAlert(message: string): Promise<void>;
    // ... 20 more methods
}

The Interface Segregation Principle

Good connectors relate directly to the Interface Segregation Principle (ISP)—clients shouldn't depend on methods they don't use. Small, focused interfaces make components easier to implement, test, and substitute. Multiple small interfaces are better than one large one.

Component Quality and Reliability

In manufacturing, component quality is paramount. A single defective part can cause an entire assembly to fail—think of how one faulty chip can make an entire device malfunction. Quality control happens at multiple levels: parts are tested before assembly, assemblies are tested before integration, and final products undergo complete testing.

Software assembly requires the same multi-level quality approach:

Multi-Level Quality Control in Software Assembly
Level	Manufacturing Equivalent	Software Practice
Component Testing	Part inspection before assembly	Unit tests for each class/module in isolation
Subassembly Testing	Testing assembled subsystems	Integration tests for composed components
Interface Conformance	Verifying parts meet spec	Contract tests ensuring implementations satisfy interfaces
Assembly Validation	Testing the completed product	End-to-end tests for the full system
Production Monitoring	Ongoing quality checks in use	Runtime monitoring, error tracking, health checks

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
// Multi-level testing for composed systems
 
// Level 1: Component unit tests
describe('TaxCalculator', () => {
    const calculator = new TaxCalculator(testTaxRates);
    
    it('calculates tax correctly for taxable items', () => {
        expect(calculator.calculate(100, 'NY')).toBe(8);  // 8% NY tax
    });
    
    it('returns 0 for tax-exempt items', () => {
        expect(calculator.calculate(100, 'NY', { category: 'groceries' })).toBe(0);
    });
});
 
// Level 2: Interface conformance tests (contract tests)
// Run against ANY implementation of the interface
function runStorageContractTests(createStorage: () => DocumentStorage) {
    describe('DocumentStorage Contract', () => {
        let storage: DocumentStorage;
        
        beforeEach(() => { storage = createStorage(); });
        
        it('load returns what was saved', async () => {
            await storage.save('doc1', 'content');
            expect(await storage.load('doc1')).toBe('content');
        });
        
        it('load returns null for non-existent documents', async () => {
            expect(await storage.load('nonexistent')).toBeNull();
        });
        
        it('delete removes documents', async () => {
            await storage.save('doc1', 'content');
            await storage.delete('doc1');
            expect(await storage.load('doc1')).toBeNull();
        });
        
        it('exists returns true for saved documents', async () => {
            await storage.save('doc1', 'content');
            expect(await storage.exists('doc1')).toBe(true);
        });
    });
}
 
// Run contract tests against all implementations
runStorageContractTests(() => new InMemoryStorage());
runStorageContractTests(() => new FileSystemStorage('./test-tmp'));
runStorageContractTests(() => new S3Storage('test-bucket', mockS3Client));
 
// Level 3: Integration tests for composed objects
describe('DocumentService (integration)', () => {
    it('round-trips documents through full stack', async () => {
        const storage = new FileSystemStorage('./test-tmp');
        const service = new DocumentService(storage);
        
        const doc = { id: 'test-123', title: 'Test', content: 'Hello' };
        await service.saveDocument(doc);
        
        const loaded = await service.getDocument('test-123');
        expect(loaded).toEqual(doc);
    });
});

Contract Tests Are Key

Contract tests verify that implementations satisfy their interface promises. Write them once against the interface, then run them against every implementation. This guarantees interchangeability—if an implementation passes the contract tests, it will work wherever that interface is expected.

Modular Evolution: Upgrading Parts Without Rebuilding Systems

A major advantage of assembly-based manufacturing is modular evolution. You can improve one part—make it more efficient, more durable, cheaper—and drop it into existing products without redesigning everything. Cars get better engines without new body designs. Phones get better cameras without new screen technology.

Software composition enables the same pattern. When components are properly isolated behind interfaces, you can evolve them independently:

Modes of Component Evolution

•Performance optimization: Replace a slow implementation with a faster one. LinearSearchIndex → HashBasedIndex with no consumer changes.
•Vendor migration: Switch providers without rewriting integration logic. StripePayments → SquarePayments using same PaymentGateway interface.
•Capability addition: Enhance a component with new features. BasicLogger → StructuredLogger with richer output, same interface.
•Bug fixes in isolation: Fix issues in one component without touching others. Correct TaxCalculator rounding without changing OrderService.
•Technology refresh: Upgrade underlying technology. SqliteDatabase → PostgresDatabase with same repository interfaces.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
// Evolution in action: Upgrading payment processing without system changes
 
// Version 1: Simple synchronous processing (adequate for MVP)
class SimplePaymentGateway implements PaymentGateway {
    async charge(amount: number, card: CardInfo): Promise<ChargeResult> {
        const response = await stripe.charges.create({
            amount,
            source: card.token
        });
        return { success: response.status === 'succeeded', id: response.id };
    }
}
 
// Version 2: Adds retry logic (evolved for reliability)
class ReliablePaymentGateway implements PaymentGateway {
    private retryPolicy = new ExponentialBackoff(3, 1000);
    
    async charge(amount: number, card: CardInfo): Promise<ChargeResult> {
        return this.retryPolicy.execute(async () => {
            const response = await stripe.charges.create({ amount, source: card.token });
            return { success: response.status === 'succeeded', id: response.id };
        });
    }
}
 
// Version 3: Adds fraud detection (evolved for security)
class SecurePaymentGateway implements PaymentGateway {
    constructor(
        private underlying: PaymentGateway,
        private fraudDetector: FraudDetector
    ) {}
    
    async charge(amount: number, card: CardInfo): Promise<ChargeResult> {
        const riskScore = await this.fraudDetector.assess(amount, card);
        if (riskScore > 0.8) {
            return { success: false, id: '', reason: 'high_risk' };
        }
        return this.underlying.charge(amount, card);
    }
}
 
// Evolution is transparent to consumers
const checkout = new CheckoutService(paymentGateway);
// ^^ Works with any version—Simple, Reliable, or Secure
 
// Configuration determines which evolution stage is deployed
const paymentGateway = config.environment === 'production'
    ? new SecurePaymentGateway(
        new ReliablePaymentGateway(),
        new MLBasedFraudDetector()
      )
    : new SimplePaymentGateway();

The Decorator Pattern

Notice how SecurePaymentGateway wraps another PaymentGateway—this is the Decorator pattern. Decorators add functionality while maintaining the same interface, enabling evolution through layering rather than modification. You can stack decorators: logging, caching, retry, metrics—each adding capability without changing the core.

Assembly Configuration: Building Product Variants

Manufacturers often produce product variants from the same set of parts. A car might be available with different engines, trim levels, or option packages—all assembled from the same basic components, just configured differently.

Software assembly enables the same flexibility through configuration-driven composition. Different configurations produce different product variants from the same component library:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
// Configuration-driven assembly: Different products from same components
 
interface AppConfig {
    edition: 'community' | 'professional' | 'enterprise';
    environment: 'development' | 'staging' | 'production';
    features: {
        analytics: boolean;
        sso: boolean;
        advancedReporting: boolean;
        multiTenancy: boolean;
    };
}
 
class ApplicationAssembler {
    assemble(config: AppConfig): Application {
        // Base components used by all editions
        const logger = this.createLogger(config);
        const database = this.createDatabase(config);
        const auth = this.createAuth(config);
        
        // Edition-specific components
        const features = this.assembleFeatures(config);
        
        // Compose the application
        return new Application({
            logger,
            database,
            auth,
            ...features
        });
    }
    
    private createAuth(config: AppConfig): AuthService {
        if (config.features.sso) {
            return new SsoAuthService(this.createSsoProvider(config));
        }
        return new BasicAuthService();
    }
    
    private assembleFeatures(config: AppConfig): Partial<ApplicationComponents> {
        const features: Partial<ApplicationComponents> = {};
        
        if (config.features.analytics) {
            features.analytics = config.edition === 'enterprise'
                ? new EnterpriseAnalytics()
                : new BasicAnalytics();
        }
        
        if (config.features.advancedReporting) {
            features.reporting = new AdvancedReportingEngine();
        } else {
            features.reporting = new BasicReportingEngine();
        }
        
        if (config.features.multiTenancy) {
            features.tenantManager = new MultiTenantManager();
        }
        
        return features;
    }
    
    private createDatabase(config: AppConfig): Database {
        switch (config.environment) {
            case 'development':
                return new SqliteDatabase('./dev.db');
            case 'staging':
                return new PostgresDatabase(process.env.STAGING_DB_URL!);
            case 'production':
                return new PostgresDatabase(process.env.PROD_DB_URL!, {
                    poolSize: 20,
                    ssl: true,
                    readReplicas: getReadReplicaUrls()
                });
        }
    }
}
 
// Different configurations produce different products
const communityApp = assembler.assemble({
    edition: 'community',
    environment: 'production',
    features: { analytics: false, sso: false, advancedReporting: false, multiTenancy: false }
});
 
const enterpriseApp = assembler.assemble({
    edition: 'enterprise',
    environment: 'production',
    features: { analytics: true, sso: true, advancedReporting: true, multiTenancy: true }
});

Benefits of configuration-driven assembly:

Configuration-Driven Assembly Benefits

•Product line from one codebase: Maintain community, pro, and enterprise editions without separate codebases.
•Environment adaptation: Same code runs in dev, staging, and production with appropriate components.
•Feature flags: Enable/disable features through configuration without code changes.
•A/B testing: Assemble variants for different user cohorts.
•Progressive rollout: Gradually introduce new components by changing configuration.

Assembly Anti-Patterns: What Breaks Modularity

Just as manufacturing can suffer from poor part design or assembly processes, software composition can go wrong. Here are anti-patterns that break the benefits of modular assembly:

Assembly Anti-Patterns

•Welded components: Parts that are so tightly coupled they can't be separated—like hard-coded database connections inside business logic. Prevents substitution and testing.
•Missing specifications: No interface definition, just concrete classes—future implementations will need to reverse-engineer what's expected. Prevents reliable interchangeability.
•Leaky abstractions: Interfaces that expose implementation details—consumers come to depend on specifics, breaking substitution. Prevents clean evolution.
•Circular dependencies: Part A requires Part B which requires Part A—can't test, assemble, or reason about either in isolation. Prevents modular construction.
•God components: One massive component that does everything—defeats the purpose of assembly. Prevents parallel development and isolated testing.
•Implicit wiring: Dependencies obtained through global singletons or service locators rather than explicit injection—invisible coupling, hard to track and test.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// Anti-pattern examples
 
// ANTI-PATTERN: Welded components (can't substitute or test)
class WeldedOrderService {
    async processOrder(order: Order): Promise<void> {
        // Directly instantiates dependencies - no way to substitute
        const db = new PostgresDatabase(process.env.DB_URL);
        const payment = new StripePaymentGateway(process.env.STRIPE_KEY);
        const email = new SendGridMailer(process.env.SENDGRID_KEY);
        
        // ...
    }
}
 
// FIXED: Injected components (testable, substitutable)
class FlexibleOrderService {
    constructor(
        private database: Database,
        private payment: PaymentGateway,
        private mailer: EmailSender
    ) {}
    
    async processOrder(order: Order): Promise<void> {
        // Uses whatever implementations were injected
    }
}
 
// ANTI-PATTERN: Leaky abstraction (exposes implementation)
interface LeakyCache {
    get(key: string): Promise<string | null>;
    set(key: string, value: string): Promise<void>;
    getRedisClient(): Redis; // Leaks Redis implementation!
}
 
// FIXED: Clean abstraction
interface CleanCache {
    get(key: string): Promise<string | null>;
    set(key: string, value: string, options?: CacheOptions): Promise<void>;
    delete(key: string): Promise<boolean>;
    // No implementation details exposed
}

The Cost of Anti-Patterns

These anti-patterns often feel faster initially—skipping interfaces, hard-coding dependencies. But they accumulate as technical debt that makes the system increasingly rigid, hard to test, and expensive to change. The time "saved" is borrowed against future maintenance cost.

Summary: Composition as Assembly

We've explored composition through the lens of manufacturing assembly—a metaphor that illuminates deep principles of modular software design. Let's consolidate the key insights:

Key Takeaways

•The assembly metaphor clarifies design — Thinking of components as manufactured parts promotes clear interfaces, minimal dependencies, and predictable behavior.
•Interchangeability enables flexibility — When implementations satisfy interface contracts, they can be swapped for testing, different environments, or evolutionary upgrades.
•Interfaces are standardized connectors — Well-designed interfaces define stable attachment points that many implementations can satisfy.
•Quality control operates at multiple levels — Unit tests, contract tests, integration tests, and monitoring ensure reliability throughout the assembly.
•Modular evolution preserves system stability — Upgrade components independently without risking the broader system.
•Configuration drives product variants — Same components, different assemblies, multiple product editions.
•Anti-patterns break modularity — Welded components, leaky abstractions, and implicit wiring defeat the benefits of compositional design.

Module Summary:

Across these four pages, we've established a comprehensive understanding of composition:

Definition: Composition means building with HAS-A relationships and delegation
Mechanics: Objects contain other objects through references, with patterns for injection and lifecycle management
Construction: Complex objects are built from simple ones using hierarchies, builders, factories, and DI containers
Philosophy: The assembly metaphor reveals composition as the key to flexible, evolvable systems

This foundation prepares you to reason about when composition is appropriate versus inheritance—the critical choice explored in the next modules.

Module Complete

You now understand composition comprehensively—its definition, mechanics, construction patterns, and the assembly philosophy that guides good compositional design. With this foundation, you're ready to explore the HAS-A vs IS-A distinction and learn when to choose composition over inheritance.