Design Principles

Author: Htunn Thu Thu
Date: January 4, 2026
Tags: #SoftwareDesign #TypeScript #DRY #KISS #YAGNI #BestPractices

Introduction

Beyond SOLID, there are fundamental design principles that guide everyday coding decisions. When I started building my IoT monitoring platform, I overengineered everything—abstract factories for simple objects, inheritance hierarchies five levels deep, and "flexible" architectures for features I never built.

These principles—DRY, KISS, YAGNI, Separation of Concerns, and Composition over Inheritance—taught me to build software that's simple, maintainable, and just complex enough to solve real problems.

DRY: Don't Repeat Yourself

Every piece of knowledge should have a single, authoritative representation.

The Problem I Had

In my Agentic LLM Search project, I had error handling code duplicated everywhere:

// ❌ BAD: Repeated error handling logic

async function searchWeb(query: string): Promise<SearchResult[]> {
  try {
    const response = await fetch(`https://api.duckduckgo.com/?q=${query}`);
    if (!response.ok) {
      console.error(`Search failed: ${response.status} ${response.statusText}`);
      throw new Error(`HTTP ${response.status}: ${response.statusText}`);
    }
    const data = await response.json();
    return data.results;
  } catch (error) {
    console.error('Error in searchWeb:', error);
    if (error instanceof TypeError) {
      throw new Error('Network error - check your connection');
    }
    throw error;
  }
}

async function queryLLM(prompt: string): Promise<string> {
  try {
    const response = await fetch('http://localhost:8000/generate', {
      method: 'POST',
      body: JSON.stringify({ prompt })
    });
    if (!response.ok) {
      console.error(`LLM failed: ${response.status} ${response.statusText}`);
      throw new Error(`HTTP ${response.status}: ${response.statusText}`);
    }
    const data = await response.json();
    return data.text;
  } catch (error) {
    console.error('Error in queryLLM:', error);
    if (error instanceof TypeError) {
      throw new Error('Network error - check your connection');
    }
    throw error;
  }
}

// Same pattern repeated in 15+ functions!

My Solution: Extract Common Logic

I created reusable utilities:

// ✅ GOOD: Single source of truth for common patterns

class APIClient {
  async fetchJSON<T>(
    url: string,
    options?: RequestInit
  ): Promise<T> {
    try {
      const response = await fetch(url, options);
      
      if (!response.ok) {
        throw new HTTPError(
          response.status,
          response.statusText,
          url
        );
      }
      
      return await response.json();
    } catch (error) {
      if (error instanceof TypeError) {
        throw new NetworkError('Network error - check your connection', url);
      }
      throw error;
    }
  }
  
  async post<T>(url: string, body: any): Promise<T> {
    return this.fetchJSON<T>(url, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(body)
    });
  }
}

// Custom error classes for better error handling
class HTTPError extends Error {
  constructor(
    public statusCode: number,
    public statusText: string,
    public url: string
  ) {
    super(`HTTP ${statusCode}: ${statusText} (${url})`);
    this.name = 'HTTPError';
  }
}

class NetworkError extends Error {
  constructor(message: string, public url: string) {
    super(`${message} (${url})`);
    this.name = 'NetworkError';
  }
}

// Now my functions are clean and DRY
const apiClient = new APIClient();

async function searchWeb(query: string): Promise<SearchResult[]> {
  const data = await apiClient.fetchJSON<{ results: SearchResult[] }>(
    `https://api.duckduckgo.com/?q=${encodeURIComponent(query)}`
  );
  return data.results;
}

async function queryLLM(prompt: string): Promise<string> {
  const data = await apiClient.post<{ text: string }>(
    'http://localhost:8000/generate',
    { prompt }
  );
  return data.text;
}

When DRY Goes Wrong

I learned the hard way that "similar looking" code isn't always duplication:

// ⚠️ CAREFUL: Similar code with different purposes

// These look similar but serve different business purposes
async function calculateUserDiscount(userId: string): Promise<number> {
  const user = await userRepo.findById(userId);
  const orders = await orderRepo.findByUser(userId);
  
  if (orders.length > 10) return 0.15;  // 15% for loyal customers
  if (user.isPremium) return 0.10;       // 10% for premium
  return 0.05;                            // 5% standard
}

async function calculatePartnerDiscount(partnerId: string): Promise<number> {
  const partner = await partnerRepo.findById(partnerId);
  const orders = await orderRepo.findByPartner(partnerId);
  
  if (orders.length > 10) return 0.20;   // 20% for volume partners
  if (partner.isVIP) return 0.15;        // 15% for VIP
  return 0.05;                            // 5% standard
}

// ❌ DON'T extract this into one function just because it looks similar
// They have different business rules and will evolve independently

My DRY Rule

Extract when:

Logic is identical and will change together
Changes to one copy should affect all copies
The duplication is accidental, not intentional

Keep separate when:

Similar code serves different business purposes
Changes to one should NOT affect the other
Different stakeholders own different pieces

KISS: Keep It Simple, Stupid

Simplicity should be a key goal, and unnecessary complexity avoided.

The Problem I Had

In my MCP server, I tried to make port scanning "flexible" for future needs:

// ❌ BAD: Over-engineered for imaginary future requirements

interface ScanStrategy {
  scan(target: Target): Promise<Result>;
}

interface Target {
  getHost(): string;
  getPorts(): number[];
  getProtocol(): Protocol;
  getTimeout(): number;
  getRetryPolicy(): RetryPolicy;
}

class AdvancedTarget implements Target {
  constructor(
    private config: TargetConfig,
    private metadata: TargetMetadata,
    private options: ScanOptions
  ) {}
  
  getHost(): string { return this.config.host; }
  getPorts(): number[] { return this.config.ports; }
  // ... 10 more methods
}

class PortScanStrategyFactory {
  createStrategy(type: ScanType): ScanStrategy {
    switch (type) {
      case 'TCP_CONNECT':
        return new TCPConnectStrategy(
          new DefaultSocketFactory(),
          new ExponentialBackoffRetryPolicy()
        );
      case 'SYN_SCAN':
        return new SYNScanStrategy(/* complex setup */);
      // ... 5 more strategies I never used
    }
  }
}

// To scan one port on one host, I needed:
const factory = new PortScanStrategyFactory();
const strategy = factory.createStrategy('TCP_CONNECT');
const target = new AdvancedTarget(
  new TargetConfig('example.com', [443]),
  new TargetMetadata(),
  new ScanOptions()
);
const result = await strategy.scan(target);

// All this for what should be a simple function call!

My Solution: Start Simple

I rewrote it with just what I actually needed:

// ✅ GOOD: Simple and clear

async function checkPort(host: string, port: number, timeoutMs = 5000): Promise<boolean> {
  return new Promise((resolve) => {
    const socket = new net.Socket();
    
    socket.setTimeout(timeoutMs);
    socket.on('connect', () => {
      socket.destroy();
      resolve(true);
    });
    socket.on('timeout', () => {
      socket.destroy();
      resolve(false);
    });
    socket.on('error', () => {
      resolve(false);
    });
    
    socket.connect(port, host);
  });
}

// Usage is dead simple
const isOpen = await checkPort('example.com', 443);

// When I actually needed to scan multiple ports, I added:
async function checkPorts(
  host: string, 
  ports: number[]
): Promise<Map<number, boolean>> {
  const results = new Map<number, boolean>();
  
  for (const port of ports) {
    results.set(port, await checkPort(host, port));
  }
  
  return results;
}

When Complexity is Justified

Later, I did need to add timeout configuration and parallel scanning. I added complexity only when the requirement was real:

// ✅ GOOD: Added complexity only when needed

interface ScanOptions {
  timeout?: number;
  parallel?: boolean;
  maxConcurrent?: number;
}

async function checkPorts(
  host: string,
  ports: number[],
  options: ScanOptions = {}
): Promise<Map<number, boolean>> {
  const { timeout = 5000, parallel = false, maxConcurrent = 10 } = options;
  const results = new Map<number, boolean>();
  
  if (parallel) {
    // Only added when I actually needed parallel scanning
    const chunks = chunkArray(ports, maxConcurrent);
    for (const chunk of chunks) {
      const promises = chunk.map(port => checkPort(host, port, timeout));
      const chunkResults = await Promise.all(promises);
      chunk.forEach((port, i) => results.set(port, chunkResults[i]));
    }
  } else {
    for (const port of ports) {
      results.set(port, await checkPort(host, port, timeout));
    }
  }
  
  return results;
}

function chunkArray<T>(array: T[], size: number): T[][] {
  const chunks: T[][] = [];
  for (let i = 0; i < array.length; i += size) {
    chunks.push(array.slice(i, i + size));
  }
  return chunks;
}

My KISS Rule

Start with the simplest solution that works
Add complexity only when you have a real requirement
Refactor when simple becomes inadequate
Delete code if a simpler approach emerges

YAGNI: You Aren't Gonna Need It

Don't implement something until it is necessary.

The Problem I Had

Building my IoT platform, I anticipated "future requirements":

// ❌ BAD: Built features I never used

class SensorDataProcessor {
  // I thought I'd need real-time streaming
  async streamData(callback: (data: SensorData) => void): Promise<void> {
    // Complex WebSocket implementation
    // Never used - batch processing was enough!
  }
  
  // I thought I'd need multiple export formats
  async exportToXML(sensorId: string): Promise<string> {
    // Complex XML generation
    // Never used - only needed JSON!
  }
  
  async exportToProtobuf(sensorId: string): Promise<Buffer> {
    // Protocol buffer encoding
    // Never used!
  }
  
  // I thought I'd need complex aggregations
  async calculateMovingAverage(
    sensorId: string,
    windowSize: number,
    algorithm: 'simple' | 'exponential' | 'weighted'
  ): Promise<number[]> {
    // Complex statistics
    // Never used - simple averages were enough!
  }
  
  // Actually needed functionality buried in unused code
  async getLatestReading(sensorId: string): Promise<SensorData> {
    // The only method I actually used!
    return this.repo.findLatest(sensorId);
  }
}

Cost of this over-engineering:

2 weeks development time wasted
Increased codebase complexity
More bugs in code nobody used
Harder to find the methods I actually needed

My Solution: Build What's Needed

I refactored to only what I actually use:

// ✅ GOOD: Only what I actually need

class SensorDataService {
  constructor(private repo: SensorRepository) {}
  
  async getLatestReading(sensorId: string): Promise<SensorData> {
    return this.repo.findLatest(sensorId);
  }
  
  async getReadings(
    sensorId: string,
    startTime: Date,
    endTime: Date
  ): Promise<SensorData[]> {
    return this.repo.findByTimeRange(sensorId, startTime, endTime);
  }
  
  async exportToJSON(sensorId: string): Promise<string> {
    const data = await this.repo.findAll(sensorId);
    return JSON.stringify(data, null, 2);
  }
}

// When I actually needed averages later, I added just that:
async getAverageReading(
  sensorId: string,
  period: 'hour' | 'day' | 'week'
): Promise<number> {
  const readings = await this.getReadingsForPeriod(sensorId, period);
  const sum = readings.reduce((acc, r) => acc + r.value, 0);
  return sum / readings.length;
}

When to Plan Ahead

YAGNI doesn't mean zero planning. I do consider:

// ✅ GOOD: Designing for known extension points without over-implementing

interface DataExporter {
  export(data: SensorData[]): Promise<string>;
}

// Implement only what I need now
class JSONExporter implements DataExporter {
  async export(data: SensorData[]): Promise<string> {
    return JSON.stringify(data, null, 2);
  }
}

class ExportService {
  private exporters = new Map<string, DataExporter>();
  
  constructor() {
    // Only register the exporter I actually use
    this.exporters.set('json', new JSONExporter());
  }
  
  async export(data: SensorData[], format: string): Promise<string> {
    const exporter = this.exporters.get(format);
    if (!exporter) {
      throw new Error(`Unknown format: ${format}`);
    }
    return exporter.export(data);
  }
  
  // Easy to add new exporters when actually needed
  registerExporter(format: string, exporter: DataExporter): void {
    this.exporters.set(format, exporter);
  }
}

// When I actually need CSV export later:
class CSVExporter implements DataExporter {
  async export(data: SensorData[]): Promise<string> {
    // Implement only when needed
    return ''; // Implementation
  }
}

exportService.registerExporter('csv', new CSVExporter());

My YAGNI Rule

Build it when:

You have a concrete requirement RIGHT NOW
Stakeholders are actively asking for it
You're currently blocked without it

Don't build it when:

"We might need this someday"
"It would be cool to have"
"What if the requirements change to..."

Separation of Concerns

Different concerns should be separated into different modules.

The Problem I Had

My early MCP server mixed everything together:

// ❌ BAD: Everything in one place

class MCPServer {
  async handleRequest(request: Request): Promise<Response> {
    // Concern 1: Request parsing
    const body = await request.json();
    const toolName = body.tool;
    const params = body.params;
    
    // Concern 2: Validation
    if (!toolName || !params) {
      return new Response(JSON.stringify({ error: 'Invalid request' }), {
        status: 400,
        headers: { 'Content-Type': 'application/json' }
      });
    }
    
    // Concern 3: Logging
    console.log(`[${new Date().toISOString()}] ${toolName} called`);
    
    // Concern 4: Business logic
    let result;
    if (toolName === 'port_scan') {
      const socket = new net.Socket();
      // Port scanning logic inline
      result = await new Promise((resolve) => {
        socket.connect(params.port, params.host);
        socket.on('connect', () => resolve({ open: true }));
      });
    }
    
    // Concern 5: Database logging
    await mongoClient.db('logs').collection('requests').insertOne({
      tool: toolName,
      params,
      result,
      timestamp: new Date()
    });
    
    // Concern 6: Response formatting
    return new Response(JSON.stringify({
      success: true,
      data: result,
      timestamp: new Date().toISOString()
    }), {
      status: 200,
      headers: { 'Content-Type': 'application/json' }
    });
  }
}

My Solution: Separate Layers

I separated concerns into distinct layers:

// ✅ GOOD: Separated concerns

// Layer 1: Request/Response handling (HTTP concern)
class MCPRequestHandler {
  constructor(
    private validator: RequestValidator,
    private toolExecutor: ToolExecutor,
    private logger: Logger
  ) {}
  
  async handleRequest(request: Request): Promise<Response> {
    const body = await request.json();
    
    const validation = this.validator.validate(body);
    if (!validation.valid) {
      return this.errorResponse(400, validation.error);
    }
    
    try {
      const result = await this.toolExecutor.execute(
        body.tool,
        body.params
      );
      return this.successResponse(result);
    } catch (error) {
      this.logger.error('Tool execution failed', error as Error);
      return this.errorResponse(500, (error as Error).message);
    }
  }
  
  private successResponse(data: any): Response {
    return new Response(JSON.stringify({
      success: true,
      data,
      timestamp: new Date().toISOString()
    }), {
      status: 200,
      headers: { 'Content-Type': 'application/json' }
    });
  }
  
  private errorResponse(status: number, message: string): Response {
    return new Response(JSON.stringify({
      success: false,
      error: message
    }), {
      status,
      headers: { 'Content-Type': 'application/json' }
    });
  }
}

// Layer 2: Validation (data validation concern)
class RequestValidator {
  validate(request: any): ValidationResult {
    if (!request.tool || typeof request.tool !== 'string') {
      return { valid: false, error: 'Tool name required' };
    }
    if (!request.params || typeof request.params !== 'object') {
      return { valid: false, error: 'Parameters required' };
    }
    return { valid: true };
  }
}

// Layer 3: Business logic (domain concern)
class ToolExecutor {
  private tools = new Map<string, Tool>();
  
  constructor(
    private logger: Logger,
    private auditLog: AuditLog
  ) {}
  
  registerTool(name: string, tool: Tool): void {
    this.tools.set(name, tool);
  }
  
  async execute(toolName: string, params: any): Promise<any> {
    const tool = this.tools.get(toolName);
    if (!tool) {
      throw new Error(`Unknown tool: ${toolName}`);
    }
    
    this.logger.info(`Executing ${toolName}`, params);
    const result = await tool.execute(params);
    
    await this.auditLog.log({
      tool: toolName,
      params,
      result,
      timestamp: new Date()
    });
    
    return result;
  }
}

// Layer 4: Infrastructure (database concern)
class AuditLog {
  constructor(private db: Db) {}
  
  async log(entry: AuditEntry): Promise<void> {
    await this.db.collection('audit_log').insertOne(entry);
  }
  
  async query(filter: AuditFilter): Promise<AuditEntry[]> {
    return await this.db.collection('audit_log')
      .find(filter)
      .toArray();
  }
}

// Layer 5: Cross-cutting (logging concern)
class Logger {
  info(message: string, context?: any): void {
    console.log(`[INFO] ${new Date().toISOString()} - ${message}`, context || '');
  }
  
  error(message: string, error: Error): void {
    console.error(`[ERROR] ${new Date().toISOString()} - ${message}`, error);
  }
}

Benefits I Gained

Testability: Each layer can be tested independently
Reusability: Logger and AuditLog used across my entire project
Maintainability: Database changes don't affect HTTP handling
Clarity: Each file has a clear, single purpose

Composition Over Inheritance

Favor object composition over class inheritance.

The Problem I Had

I tried using inheritance for my sensor types:

// ❌ BAD: Deep inheritance hierarchy

class Sensor {
  constructor(protected id: string) {}
  
  getData(): SensorData {
    throw new Error('Must implement');
  }
}

class NetworkedSensor extends Sensor {
  constructor(id: string, protected ipAddress: string) {
    super(id);
  }
  
  ping(): Promise<boolean> {
    // Network capabilities
    return Promise.resolve(true);
  }
}

class StoredSensor extends NetworkedSensor {
  constructor(
    id: string,
    ipAddress: string,
    private db: Database
  ) {
    super(id, ipAddress);
  }
  
  async save(): Promise<void> {
    await this.db.save(this.getData());
  }
}

class AIEnabledStoredSensor extends StoredSensor {
  constructor(
    id: string,
    ipAddress: string,
    db: Database,
    private llm: LLMService
  ) {
    super(id, ipAddress, db);
  }
  
  async analyze(): Promise<string> {
    return this.llm.query(`Analyze: ${JSON.stringify(this.getData())}`);
  }
}

// Problem: What if I need AI without storage? Or storage without network?
// The hierarchy forces coupling that doesn't match my needs!

My Solution: Use Composition

I broke capabilities into composable pieces:

// ✅ GOOD: Composable capabilities

// Core sensor (minimal base class)
class Sensor {
  constructor(
    public readonly id: string,
    private data: SensorData
  ) {}
  
  getData(): SensorData {
    return this.data;
  }
  
  updateData(data: SensorData): void {
    this.data = data;
  }
}

// Composable capabilities
interface NetworkCapability {
  ping(): Promise<boolean>;
  getIPAddress(): string;
}

interface StorageCapability {
  save(data: SensorData): Promise<void>;
  load(id: string): Promise<SensorData>;
}

interface AICapability {
  analyze(data: SensorData): Promise<string>;
  query(question: string, data: SensorData): Promise<string>;
}

// Implementations
class NetworkAdapter implements NetworkCapability {
  constructor(private ipAddress: string) {}
  
  async ping(): Promise<boolean> {
    // Ping implementation
    return true;
  }
  
  getIPAddress(): string {
    return this.ipAddress;
  }
}

class DatabaseStorage implements StorageCapability {
  constructor(private db: Database) {}
  
  async save(data: SensorData): Promise<void> {
    await this.db.collection('sensors').insertOne(data);
  }
  
  async load(id: string): Promise<SensorData> {
    return await this.db.collection('sensors').findOne({ id });
  }
}

class LLMAnalyzer implements AICapability {
  constructor(private llm: LLMService) {}
  
  async analyze(data: SensorData): Promise<string> {
    return this.llm.query(`Analyze: ${JSON.stringify(data)}`);
  }
  
  async query(question: string, data: SensorData): Promise<string> {
    return this.llm.query(`${question}\nContext: ${JSON.stringify(data)}`);
  }
}

// Compose capabilities as needed
class SmartSensor {
  constructor(
    private sensor: Sensor,
    private network?: NetworkCapability,
    private storage?: StorageCapability,
    private ai?: AICapability
  ) {}
  
  getId(): string {
    return this.sensor.id;
  }
  
  getData(): SensorData {
    return this.sensor.getData();
  }
  
  // Network capability (only if provided)
  async ping(): Promise<boolean> {
    if (!this.network) {
      throw new Error('Network capability not available');
    }
    return this.network.ping();
  }
  
  // Storage capability (only if provided)
  async save(): Promise<void> {
    if (!this.storage) {
      throw new Error('Storage capability not available');
    }
    await this.storage.save(this.sensor.getData());
  }
  
  // AI capability (only if provided)
  async analyze(): Promise<string> {
    if (!this.ai) {
      throw new Error('AI capability not available');
    }
    return this.ai.analyze(this.sensor.getData());
  }
}

// Now I can mix and match capabilities!

// Simple sensor (no capabilities)
const simple = new SmartSensor(
  new Sensor('temp-01', { temp: 22 })
);

// Networked sensor (only network)
const networked = new SmartSensor(
  new Sensor('temp-02', { temp: 23 }),
  new NetworkAdapter('192.168.1.100')
);

// AI-enabled with storage (no network)
const aiSensor = new SmartSensor(
  new Sensor('temp-03', { temp: 24 }),
  undefined,  // No network
  new DatabaseStorage(db),
  new LLMAnalyzer(llm)
);

// Full featured (all capabilities)
const fullSensor = new SmartSensor(
  new Sensor('temp-04', { temp: 25 }),
  new NetworkAdapter('192.168.1.101'),
  new DatabaseStorage(db),
  new LLMAnalyzer(llm)
);

Benefits I Gained

Flexibility: Mix and match capabilities without inheritance constraints
Testability: Mock individual capabilities easily
Reusability: Capabilities work with any sensor type
Clarity: Each capability is self-contained

Applying Principles Together

Here's how I apply all these principles in a real service from my IoT platform:

// Real example: Sensor data query service

// KISS: Simple interface
interface SensorQueryService {
  query(sensorId: string, question: string): Promise<string>;
}

// DRY: Reusable data retrieval
class SensorDataRetriever {
  constructor(private repo: SensorRepository) {}
  
  async getRecentData(sensorId: string, hours: number = 24): Promise<SensorData[]> {
    const since = new Date(Date.now() - hours * 60 * 60 * 1000);
    return this.repo.findByTimeRange(sensorId, since, new Date());
  }
}

// Separation of Concerns: Formatting logic separate
class PromptBuilder {
  buildContext(sensorData: SensorData[]): string {
    return sensorData
      .map(d => `Time: ${d.timestamp}, Temp: ${d.temp}°C, Humidity: ${d.humidity}%`)
      .join('\n');
  }
  
  buildPrompt(question: string, context: string): string {
    return `Answer this question about sensor data:\n${question}\n\nData:\n${context}`;
  }
}

// Composition: Combine capabilities
class LLMSensorQueryService implements SensorQueryService {
  constructor(
    private dataRetriever: SensorDataRetriever,  // Composed
    private promptBuilder: PromptBuilder,        // Composed
    private llm: LLMService                      // Composed
  ) {}
  
  async query(sensorId: string, question: string): Promise<string> {
    // YAGNI: Only implemented caching when I actually needed it
    const data = await this.dataRetriever.getRecentData(sensorId);
    
    if (data.length === 0) {
      return 'No recent data available for this sensor.';
    }
    
    const context = this.promptBuilder.buildContext(data);
    const prompt = this.promptBuilder.buildPrompt(question, context);
    
    return await this.llm.query(prompt);
  }
}

// Usage is simple (KISS)
const service = new LLMSensorQueryService(
  new SensorDataRetriever(repo),
  new PromptBuilder(),
  llm
);

const answer = await service.query('sensor-01', 'What was the average temperature today?');

Conclusion

These principles guide my daily development:

DRY: Extract duplication, but respect different purposes
KISS: Start simple, add complexity only when justified
YAGNI: Build what you need now, not what you might need
Separation of Concerns: Organize code by responsibility
Composition over Inheritance: Favor flexibility over rigid hierarchies

The key is balance—apply principles pragmatically, not dogmatically. Simple code that solves real problems beats "perfect" code that over-engineers imaginary ones.

What's Next?

SOLID Principles → - Deeper dive into object-oriented design
Creational Design Patterns → - Patterns for object creation
Component Design → - Building modular architectures

References

My IoT Monitoring Platform
The Pragmatic Programmer - Source of DRY principle
Extreme Programming - YAGNI origin

Previous: ← SOLID Principles | Next: Creational Patterns →

PreviousSOLID Principles NextCreational Design Patterns

Last updated 1 month ago

hashtagIntroduction

hashtagDRY: Don't Repeat Yourself

hashtagThe Problem I Had

hashtagMy Solution: Extract Common Logic

hashtagWhen DRY Goes Wrong

hashtagMy DRY Rule

hashtagKISS: Keep It Simple, Stupid

hashtagThe Problem I Had

hashtagMy Solution: Start Simple

hashtagWhen Complexity is Justified

hashtagMy KISS Rule

hashtagYAGNI: You Aren't Gonna Need It

hashtagThe Problem I Had

hashtagMy Solution: Build What's Needed

hashtagWhen to Plan Ahead

hashtagMy YAGNI Rule

hashtagSeparation of Concerns

hashtagThe Problem I Had

hashtagMy Solution: Separate Layers

hashtagBenefits I Gained

hashtagComposition Over Inheritance

hashtagThe Problem I Had

hashtagMy Solution: Use Composition

hashtagBenefits I Gained

hashtagApplying Principles Together

hashtagConclusion

hashtagWhat's Next?

hashtagReferences

Introduction

DRY: Don't Repeat Yourself

The Problem I Had

My Solution: Extract Common Logic

When DRY Goes Wrong

My DRY Rule

KISS: Keep It Simple, Stupid

The Problem I Had

My Solution: Start Simple

When Complexity is Justified

My KISS Rule

YAGNI: You Aren't Gonna Need It

The Problem I Had

My Solution: Build What's Needed

When to Plan Ahead

My YAGNI Rule

Separation of Concerns

The Problem I Had

My Solution: Separate Layers

Benefits I Gained

Composition Over Inheritance

The Problem I Had

My Solution: Use Composition

Benefits I Gained

Applying Principles Together

Conclusion

What's Next?

References