SOLID

// ❌ WRONG: Multiple responsibilities in one component
export function OrderProcessor() {
  // Responsibility 1: Validation
  const validateOrder = (order: Order) => {
    return order.items.length > 0;
  };

  // Responsibility 2: Price calculation
  const calculateTotal = (order: Order) => {
    let total = order.items.reduce((sum, item) => sum + item.price, 0);
    total += total * 0.08; // Tax
    return total;
  };

  // Responsibility 3: Payment processing
  const processPayment = async (order: Order, amount: number) => {
    console.log("Processing payment:", amount);
    // Payment logic
  };

  // Responsibility 4: Email notifications
  const sendEmail = async (order: Order) => {
    console.log("Sending email for order:", order.id);
    // Email logic
  };

  // All mixed together!
  const handleOrder = async (order: Order) => {
    if (!validateOrder(order)) return;
    const total = calculateTotal(order);
    if (await processPayment(order, total)) {
      await sendEmail(order);
    }
  };

  // Problems:
  // - Multiple reasons to change
  // - Hard to test
  // - Violates SRP
  // - Difficult to maintain

  return <div>...</div>;
}

// ✅ GOOD: Single Responsibility Applied
// Each function/service has ONE responsibility

// Responsibility 1: Validation only
class OrderValidator {
  validate(order: Order): boolean {
    return order.items.length > 0;
  }
}

// Responsibility 2: Price calculation only
class PriceCalculator {
  calculateTotal(order: Order): number {
    let total = order.items.reduce((sum, item) => sum + item.price, 0);
    total += total * 0.08; // Tax
    return total;
  }
}

// Responsibility 3: Payment processing only
class PaymentProcessor {
  async processPayment(order: Order, amount: number): Promise<boolean> {
    console.log("Processing payment:", amount);
    // Payment logic
    return true;
  }
}

// Responsibility 4: Email notifications only
class EmailService {
  async sendConfirmation(order: Order): Promise<void> {
    console.log("Sending email for order:", order.id);
    // Email logic
  }
}

// Orchestrator coordinates but doesn't implement logic
class OrderService {
  private validator = new OrderValidator();
  private calculator = new PriceCalculator();
  private paymentProcessor = new PaymentProcessor();
  private emailService = new EmailService();

  async processOrder(order: Order): Promise<void> {
    if (!this.validator.validate(order)) return;
    const total = this.calculator.calculateTotal(order);
    if (await this.paymentProcessor.processPayment(order, total)) {
      await this.emailService.sendConfirmation(order);
    }
  }
}

// Component only handles UI
export function OrderForm() {
  const orderService = new OrderService();

  const handleSubmit = async (order: Order) => {
    await orderService.processOrder(order);
  };

  return (
    <form onSubmit={handleSubmit}>
      {/* Form UI */}
    </form>
  );
}

// Benefits:
// ✅ Each class/function has one reason to change
// ✅ Easy to test in isolation
// ✅ Easy to maintain and modify
// ✅ Clear separation of concerns
// ✅ Reusable components

// ❌ WRONG: Must modify existing code to add new button types
const Button = ({ type, ...props }: { type: string; [key: string]: any }) => {
  // Must modify this component to add new button types
  if (type === "primary") {
    return <button className="bg-blue-500" {...props} />;
  } else if (type === "secondary") {
    return <button className="bg-gray-500" {...props} />;
  } else if (type === "danger") {
    return <button className="bg-red-500" {...props} />;
  }
  // ❌ Must add new if-else for each new type!

  return <button {...props} />;
};

// Problems:
// - Must modify component for new types
// - Violates Open/Closed Principle
// - Hard to extend

// ✅ GOOD: Open/Closed Principle Applied
// Open for extension, closed for modification

interface ButtonProps {
  onClick?: () => void;
  children: React.ReactNode;
  className?: string;
}

interface ButtonVariant {
  getClassName: () => string;
}

// Base button component (closed for modification)
const Button = ({ variant, ...props }: ButtonProps & { variant: ButtonVariant }) => {
  return (
    <button className={variant.getClassName()} {...props}>
      {props.children}
    </button>
  );
};

// Variants (open for extension)
const PrimaryButtonVariant: ButtonVariant = {
  getClassName: () => "bg-blue-500 hover:bg-blue-600 text-white",
};

const SecondaryButtonVariant: ButtonVariant = {
  getClassName: () => "bg-gray-500 hover:bg-gray-600 text-white",
};

const DangerButtonVariant: ButtonVariant = {
  getClassName: () => "bg-red-500 hover:bg-red-600 text-white",
};

// ✅ Can add new variants without modifying Button component
const SuccessButtonVariant: ButtonVariant = {
  getClassName: () => "bg-green-500 hover:bg-green-600 text-white",
};

// Usage
<Button variant={PrimaryButtonVariant}>Click me</Button>
<Button variant={SuccessButtonVariant}>Success</Button>

// Benefits:
// ✅ Add new variants without modifying Button
// ✅ Follows Open/Closed Principle
// ✅ Easy to extend
// ✅ Testable in isolation

// ❌ WRONG: Components not substitutable
const Input = ({ type, ...props }: { type: string; [key: string]: any }) => {
  if (type === "text") {
    return <input type="text" {...props} />;
  } else if (type === "number") {
    // ❌ Number input might not accept all text input props
    return <input type="number" {...props} />;
  }
  // Not substitutable - breaks when swapped
};

// Problems:
// - Not truly substitutable
// - Breaks when used interchangeably
// - Violates LSP

// ✅ GOOD: Liskov Substitution Applied
// All input types are substitutable

interface InputProps {
  value: string;
  onChange: (value: string) => void;
  placeholder?: string;
  disabled?: boolean;
}

// Base input component
const BaseInput = ({ value, onChange, placeholder, disabled, type }: InputProps & { type: string }) => {
  return (
    <input
      type={type}
      value={value}
      onChange={(e) => onChange(e.target.value)}
      placeholder={placeholder}
      disabled={disabled}
    />
  );
};

// All are substitutable - same interface
const TextInput = (props: InputProps) => (
  <BaseInput {...props} type="text" />
);

const NumberInput = (props: InputProps) => (
  <BaseInput {...props} type="number" />
);

const EmailInput = (props: InputProps) => (
  <BaseInput {...props} type="email" />
);

// Can use any input type interchangeably
function FormField({ InputComponent, ...props }: { InputComponent: React.ComponentType<InputProps> } & InputProps) {
  return <InputComponent {...props} />;
}

// All work the same way!
<FormField InputComponent={TextInput} value={text} onChange={setText} />
<FormField InputComponent={NumberInput} value={number} onChange={setNumber} />
<FormField InputComponent={EmailInput} value={email} onChange={setEmail} />

// Benefits:
// ✅ All input types are substitutable
// ✅ Same interface guarantees compatibility
// ✅ Follows Liskov Substitution Principle
// ✅ No unexpected behavior

// ❌ WRONG: High-level module depends on low-level modules
// Direct dependency on concrete implementations

type User = {
  name: string;
  email: string;
  dateOfBirth: Date;
};

// Low-level module: CSV export
class ExportUserToCSV {
  export(user: User) {
    console.log(`Exported ${user.name} to CSV`);
  }
}

// Low-level module: PDF export
class ExportUserToPDF {
  export(user: User) {
    console.log(`Exported ${user.name} to PDF`);
  }
}

// ❌ High-level module directly depends on concrete implementations
class ExportUserUseCase {
  private csvExporter = new ExportUserToCSV(); // Direct dependency!
  private pdfExporter = new ExportUserToPDF(); // Direct dependency!

  executeCSV(user: User) {
    this.csvExporter.export(user);
  }

  executePDF(user: User) {
    this.pdfExporter.export(user);
  }
}

// Problems:
// - High-level depends on low-level modules
// - Hard to test (can't inject mocks)
// - Hard to extend (must modify UseCase for new formats)
// - Violates Dependency Inversion Principle
// - Tight coupling

// ✅ GOOD: Dependency Inversion Principle Applied
// High-level modules depend on abstractions, not concrete implementations

// Step 1: Define Abstractions (Interfaces)
type User = {
  name: string;
  email: string;
  dateOfBirth: Date;
};

interface ExportUser {
  export(user: User): void;
}

// Step 2: Implement Concrete Classes
class ExportUserToCSV implements ExportUser {
  export(user: User) {
    // Logic to export user to a CSV file
    console.log(`Exported ${user.name} to CSV`);
  }
}

class ExportUserToPDF implements ExportUser {
  export(user: User) {
    // Logic to export user to a PDF file
    console.log(`Exported ${user.name} to PDF`);
  }
}

// Step 3: Use Dependency Injection
// High-level module depends on abstraction, not concrete implementation
class ExportUserUseCase {
  constructor(private exportUser: ExportUser) {} // Depends on abstraction

  execute(user: User) {
    // Export the user data using the injected dependency
    this.exportUser.export(user);
  }
}

// Usage examples:

// With CSV
const exportUsertoCSV = new ExportUserToCSV();
const exportUserUseCaseCSV = new ExportUserUseCase(exportUsertoCSV);

exportUserUseCaseCSV.execute({
  name: 'Bobson Paebi',
  email: 'paebi@bubstack.tech',
  dateOfBirth: new Date(),
});

// With PDF
const exportUsertoPDF = new ExportUserToPDF();
const exportUserUseCasePDF = new ExportUserUseCase(exportUsertoPDF);

exportUserUseCasePDF.execute({
  name: 'Bobson Paebi',
  email: 'paebi@bubstack.tech',
  dateOfBirth: new Date(),
});

// React Component Example:
export function UserExportForm() {
  const [exportFormat, setExportFormat] = useState<'csv' | 'pdf'>('csv');

  // Create the appropriate exporter based on selection
  const exporter: ExportUser = exportFormat === 'csv' 
    ? new ExportUserToCSV() 
    : new ExportUserToPDF();

  const exportUserUseCase = new ExportUserUseCase(exporter);

  const handleExport = (user: User) => {
    exportUserUseCase.execute(user);
  };

  return (
    <form onSubmit={(e) => {
      e.preventDefault();
      handleExport({ name: 'John', email: 'john@example.com', dateOfBirth: new Date() });
    }}>
      <select value={exportFormat} onChange={(e) => setExportFormat(e.target.value as 'csv' | 'pdf')}>
        <option value="csv">CSV</option>
        <option value="pdf">PDF</option>
      </select>
      <button type="submit">Export User</button>
    </form>
  );
}

// Benefits:
// ✅ High-level modules don't depend on low-level modules
// ✅ Both depend on abstractions
// ✅ Easy to test (can inject mocks)
// ✅ Easy to extend (add new export formats without modifying UseCase)
// ✅ Follows Dependency Inversion Principle
// ✅ Loose coupling