# SOLID Design Principles - JavaScript Coding Assistant Guidelines

(Single index.html File)

When generating, reviewing, or modifying JavaScript code within a single `index.html` file (using `<script>` tags), follow these guidelines to ensure adherence to SOLID principles:

## 1. Single Responsibility Principle (SRP)
- Each function or object in `index.html` must have only one reason to change.
- Limit function scope to a single functional area or abstraction level.
- When a `<script>` section exceeds 100-150 lines, consider if it has multiple responsibilities.
- Separate cross-cutting concerns (logging, validation, error handling) into distinct functions within the same `<script>` tag.
- Group related operations (like data access, business rules, and UI logic) into separate named functions or objects within `index.html`.
- Function names should clearly indicate their singular purpose.
- If a function description requires "and" or "or", it likely violates SRP.
- Prioritize composition over inheritance using JavaScript objects or higher-order functions within the `<script>` tag.

## 2. Open/Closed Principle (OCP)
- Design functions and objects in `index.html` to be extended without modification.
- Use object shapes or abstract-like contracts (via comments or conventions) to define stable contracts within the `<script>` tag.
- Implement extension points with callbacks or plugin-like objects for anticipated variations in the same file.
- Favor strategy patterns using functions or objects over conditional logic within `index.html`.
- Use configuration objects and dependency injection by passing arguments to functions in the `<script>` tag.
- Avoid switch/if-else chains based on type checking; use polymorphism instead.
- Provide hooks for customization (e.g., event listeners or callback patterns) within the `<script>` section.
- Design with JavaScript’s prototypal inheritance or composition for extending functionality in the single file.

## 3. Liskov Substitution Principle (LSP)
- Ensure derived objects in `index.html` are fully substitutable for their base counterparts.
- Maintain all invariants of the base object in derived implementations within the `<script>` tag.
- Never throw unexpected exceptions from functions not specified in base contracts.
- Don’t strengthen preconditions in extended objects.
- Don’t weaken postconditions in extended objects.
- Avoid overriding methods with implementations that do nothing or throw exceptions.
- Avoid type checking or downcasting, which may indicate LSP violations.
- Prefer composition (e.g., object mixing) over inheritance when substitutability is tricky within the single file.

## 4. Interface Segregation Principle (ISP)
- Create focused, minimal object shapes with cohesive methods in `index.html`.
- Split large object contracts into smaller, more specific ones within the `<script>` tag.
- Design contracts around client needs, not implementation convenience, even in a single file.
- Avoid "fat" interfaces that force clients to depend on methods they don’t use.
- Use role-based object shapes representing behaviors rather than object types.
- Implement multiple small object contracts rather than a single general-purpose one in the `<script>` section.
- Consider object composition to build complex behaviors within the same file.
- Remove any methods from contracts that are only used by a subset of implementing objects.

## 5. Dependency Inversion Principle (DIP)
- High-level functions in `index.html` should depend on abstractions (e.g., object shapes), not concrete implementations.
- Make all dependencies explicit, ideally through function parameters within the `<script>` tag.
- Use dependency injection by passing dependencies as arguments to functions in the same file.
- Program to object shapes or interfaces, not concrete functions or objects.
- Define abstractions as separate objects or functions within the `<script>` tag, distinct from implementations.
- Avoid direct instantiation of service functions with `new` or inline calls in business logic.
- Create abstraction boundaries within the `<script>` section at logical layer transitions.
- Define contracts owned by the client, not the implementation, in the single file.

## Implementation Guidelines
- When writing a new function in `index.html`, explicitly identify its single responsibility.
- Document extension points and expected behavior for composition using comments in the `<script>` tag.
- Write object contracts with clear expectations and invariants as comments or conventions.
- Question any function that depends on many concrete implementations within the same file.
- Use function arguments, factory functions, or dependency injection to manage dependencies in `index.html`.
- Review object hierarchies to ensure LSP compliance within the `<script>` section.
- Regularly refactor toward SOLID, especially when extending functionality in the single file.
- Use design patterns (Strategy, Decorator, Factory, Observer, etc.) to facilitate SOLID adherence within the `<script>` tag.

## Warning Signs
- "God" functions in `index.html` that handle everything.
- Functions with boolean parameters that radically change behavior.
- Deep prototype chains within the `<script>` section.
- Functions that know implementation details of their dependencies.
- High coupling between unrelated components in the same file.
- `<script>` sections that grow rapidly in size with new features.
- Functions with many parameters.