# 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 for files and folder.

- Use @nestjs/common for shared utilities

- Use @nestjs/config for configuration management

- Use Swagger tags when needed, all available fhor these case

## 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

- 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

## 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

## Best Practices

- Use @nestjs/swagger for API documentation

## Testing Guidelines

- Ensure Swagger documentation is up-to-date with test cases

## Documentation Guidelines 

- 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

Please review the selected code looking for issues in security.

Check for the followings potential issues, and any other detected:

  - ** Input Validation and Sanitization **
  
  - ** Authentication and Authorization **

  - ** Use HTTPS **: Ensure the application is configured to use HTTPS. 

  - ** SQL Injection Prevention **: Use ORM methods like TypeORM’s `Repository` to prevent SQL injection. 

  - ** CSRF Protection **: Enable CSRF protection if the application uses cookies and sessions. 

  - ** Rate Limiting **: Implement rate limiting toc prevent abuse and denial-of-service attacks. 

  - ** Environment Variables **: Ensure sensitive information is stored in environment variables and not hard-coded. 

  - ** Logging and Error Handling **: Avoid logging sensitive information and use structured logging. Handle errors gracefully. 

  - ** Session Management **: Use secure session management practices, such as setting appropriate cookie flags (HttpOnly, Secure). 

  - ** Cross-Site Scripting (XSS) Prevention **: Sanitize user inputs and use Content Security Policy (CSP). 

  - ** Cross-Site Request Forgery (CSRF) Protection **: Use CSRF tokens or other mitigation strategies. 

  - ** Helmet for Security Headers **: Use the `helmet` library to set various security headers. 

  - ** Database Security **: Ensure database connections are secure and use secure authentication mechanisms. 

  - ** Third-Party Libraries **: Keep third-party libraries up to date and check for known vulnerabilities. 

  - ** File Uploads **: Validate and sanitize file uploads to prevent malicious  files from being processed. 

  - ** Sensitive Data Encryption **: Encrypt sensitive data both at rest and in transit. 

  - ** CORS Configuration **: Configure Cross-Origin Resource Sharing (CORS) to allow only trusted domains.

Include in review only issues detected

Format the review as: 
  ```markdown 
    - ** <ISSUE> **
      - <CODE ISSUE DETECTED>
      - ** Explanation **: <Description of the issue and its potential impact>
      - ** Recommendation **: <Action to fix the issue>
      - ** code fixed **:
        - <CODE ISSUE FIXED>
  ```

Please review the selected code looking for issues in Code Quality.
Check for the followings potential issues, and any other detected:

  - ** Code Formatting **: Ensure consistent code formatting using a linter with usefully plugins. 
  
  - ** Readability **: Code should be easy to read and understand. Use meaningful variable and function names.
  
  - ** Commenting **: Include meaningful comments and documentation for complex logic and algorithms. 
  
  - ** DRY Principle **: Avoid code duplication. Use functions, classes, and modules to promote reusability. 
  
  - ** Error Handling **: Implement proper error handling to manage and log exceptions  effectively. 
  
  - ** Testing **: Ensure comprehensive unit tests and integration tests are written using frameworks like `Jest`.

 
Include in review only issues detected

Format the review as: 
  ```markdown 
    - ** <ISSUE> **
      - <CODE ISSUE DETECTED>
      - ** Explanation **: <Description of the issue and its potential impact>
      - ** Recommendation **: <Action to fix the issue>
      - ** code fixed **:
        - <CODE ISSUE FIXED>
  ```

Please review the selected code looking for issues in security.
Check for the followings potential issues, and any other detected:

  - ** Use TypeScript **: Ensure TypeScript is used for type safety and improved maintainability. 
  - ** Dependency Injection **: Use NestJS's dependency injection for service management. 
  - ** Configuration **: Use configuration management to handle environment-specific settings. 
  - ** Interceptors **: Use interceptors for cross-cutting concerns like logging, authentication, etc. 
  - ** Guards **: Use guards for authentication and authorization. 
  - **Pipes**: Use pipes for data transformation and validation.

Include in review only issues detected
Format the review as: 
  ```markdown 
     ** <ISSUE> **
       <CODE ISSUE DETECTED>
       ** File: ** < File paths of files with this issues >
       ** Explanation **: <Description of the issue and its potential impact>
       ** Recommendation **: <Action to fix the issue>
       ** code fixed **:
         <CODE ISSUE FIXED>
  ```