# SOLID Design Principles - Coding Assistant Guidelines

When generating, reviewing, or modifying code, follow these guidelines to ensure adherence to SOLID principles:

## 1. Single Responsibility Principle (SRP)

- Each class must have only one reason to change.
- Limit class scope to a single functional area or abstraction level.
- When a class exceeds 100-150 lines, consider if it has multiple responsibilities.
- Separate cross-cutting concerns (logging, validation, error handling) from business logic.
- Create dedicated classes for distinct operations like data access, business rules, and UI.
- Method names should clearly indicate their singular purpose.
- If a method description requires "and" or "or", it likely violates SRP.
- Prioritize composition over inheritance when combining behaviors.

## 2. Open/Closed Principle (OCP)

- Design classes to be extended without modification.
- Use abstract classes and interfaces to define stable contracts.
- Implement extension points for anticipated variations.
- Favor strategy patterns over conditional logic.
- Use configuration and dependency injection to support behavior changes.
- Avoid switch/if-else chains based on type checking.
- Provide hooks for customization in frameworks and libraries.
- Design with polymorphism as the primary mechanism for extending functionality.

## 3. Liskov Substitution Principle (LSP)

- Ensure derived classes are fully substitutable for their base classes.
- Maintain all invariants of the base class in derived classes.
- Never throw exceptions from methods that don't specify them in base classes.
- Don't strengthen preconditions in subclasses.
- Don't weaken postconditions in subclasses.
- Never override methods with implementations that do nothing or throw exceptions.
- Avoid type checking or downcasting, which may indicate LSP violations.
- Prefer composition over inheritance when complete substitutability can't be achieved.

## 4. Interface Segregation Principle (ISP)

- Create focused, minimal interfaces with cohesive methods.
- Split large interfaces into smaller, more specific ones.
- Design interfaces around client needs, not implementation convenience.
- Avoid "fat" interfaces that force clients to depend on methods they don't use.
- Use role interfaces that represent behaviors rather than object types.
- Implement multiple small interfaces rather than a single general-purpose one.
- Consider interface composition to build up complex behaviors.
- Remove any methods from interfaces that are only used by a subset of implementing classes.

## 5. Dependency Inversion Principle (DIP)

- High-level modules should depend on abstractions, not details.
- Make all dependencies explicit, ideally through constructor parameters.
- Use dependency injection to provide implementations.
- Program to interfaces, not concrete classes.
- Place abstractions in a separate package/namespace from implementations.
- Avoid direct instantiation of service classes with 'new' in business logic.
- Create abstraction boundaries at architectural layer transitions.
- Define interfaces owned by the client, not the implementation.

## Implementation Guidelines

- When starting a new class, explicitly identify its single responsibility.
- Document extension points and expected subclassing behavior.
- Write interface contracts with clear expectations and invariants.
- Question any class that depends on many concrete implementations.
- Use factories, dependency injection, or service locators to manage dependencies.
- Review inheritance hierarchies to ensure LSP compliance.
- Regularly refactor toward SOLID, especially when extending functionality.
- Use design patterns (Strategy, Decorator, Factory, Observer, etc.) to facilitate SOLID adherence.

## Warning Signs

- God classes that do "everything"
- Methods with boolean parameters that radically change behavior
- Deep inheritance hierarchies
- Classes that need to know about implementation details of their dependencies
- Circular dependencies between modules
- High coupling between unrelated components
- Classes that grow rapidly in size with new features
- Methods with many parameters

## Introduction
- These rules are applicable to NestJS 9 projects
## Project Setup
- Use Nest CLI for project scaffolding
- Use TypeScript with strict mode enabled
- Use TypeORM for database operations
## Code Style
- Follow NestJS coding style guide
- Use the typical naming conventions:
  - Controllers: .controller.ts
  - Services: .service.ts
  - Modules: .module.ts
- Use @nestjs/common for shared utilities
- Use @nestjs/config for configuration management
- Use Swagger 3.1
## Best Practices
- Adhere to NestJS's official best practices and guidelines
- Prefer use of DTOs (Data Transfer Objects) for data validation
- Keep controllers focused on handling requests and responses
- Use services for business logic and data management
- Use TypeORM for database operations
- Avoid overusing services
- Keep logic simple and focused on the task at hand
- Use @nestjs/swagger for API documentation
- Follow NestJs Swagger best practices and for how to create and maintain the project architecture 
## Testing
- Write comprehensive unit tests and integration tests
- Use Jest and Supertest for testing
## Documentation
- Doc code with jsdoc
- Use clear and descriptive comments
- Provide documentation for complex logic and algorithms
## Security
- Validate user input to prevent SQL injection attacks
- Use authentication and authorization mechanisms to protect routes and data
- Avoid using `any` type
- Use asynchronous programming for non-blocking operations
- Use @nestjs/security for security-related utilities
## Performance
- Optimize database queries to reduce query times
- Use caching mechanisms to reduce load on the database
- Avoid using unnecessary middleware or libraries

## Introduction
- These rules are applicable to NestJS 9 projects with Swagger 3
    
## Introduction

- These rules are applicable to NestJS 9 projects with Swagger 3.1

## Best Practices

- Use @nestjs/swagger for API documentation

## Testing Guidelines

- Ensure Swagger documentation is up-to-date with test cases## Documentation
Guidelines 

- Use Swagger 3.1 for API documentation

- Ensure Swagger documentation is comprehensive and includes:
  - API version
  - Title and description
  - Base URL
  - Endpoints with detailed descriptions
  - Request and response examples
  - Parameters and response schemas
  - Error handling and status codes
- Use markdown to format API documentation descriptions

- Keep documentation updated with code changes

## Security

- Include security headers in Swagger documentation