(function(){<br />
let canvas = document.createElement('canvas'),<br />  
ctx = canvas.getContext('2d'),<br />             
w = canvas.width = innerWidth,<br />
h = canvas.height = innerHeight,<br />
particles = [],<br />
properties = {<br />
bgColor : 'rgba(17, 17, 19, 1)',<br />
particleColor : 'rgba(255, 40, 40, 1)',<br />
particleRadius : 3,<br />
particleCount : 60,<br />
particleMaxVelocity : 0.5,<br />
lineLength : 150,<br />
particleLife : 6,<br />
};<br />
<br />
document.querySelector('body').appendChild(canvas);<br />
<br />
window.onresize = function() {<br />
w = canvas.width = innerWidth;<br />
h = canvas.height = innerHeight;<br />
}<br />
<br />
class Particle {<br />
constructor() {<br />
this.x = Math.random()*w;<br />

SOLID Principles

SRP — Single Responsibility Principle

A module should have one responsibility and therefore one reason to change. That reason should come from a single business actor.

Changes required by one client or department should not affect functionality used by another client or department.

For example, clients may include an administrator, a company, a customer, and others.

Suppose we use the same algorithm for both administrator and company logic. If we modify the algorithm to satisfy administrator requirements, it may unintentionally affect company behavior. This violates SRP. Instead, we should separate the code for different clients so that each module serves a single responsibility.

Possible solution: Introduce a Facade pattern or split the business logic into separate modules for each client.

https://en.wikipedia.org/wiki/Facade_pattern

OCP — Open/Closed Principle

Software entities should be open for extension but closed for modification.

You should be able to add new behavior without changing existing code. High-level business rules should remain stable even when low-level implementation details change.

Consider the following project structure for an application that generates reports in PDF and web formats:

Interactor — business logic (most protected layer)
Controller — application orchestration
Presenter — transforms data for the UI
View — Web / PDF
Database — infrastructure

So:

Adding a PDF view → should NOT modify interactor
Changing database → should NOT modify controller
Adding mobile UI → should NOT modify report generation logic

LSP — Liskov Substitution Principle

Subtypes must be substitutable for their base types.

Ask yourself:

Can I replace the parent class with a child class without changing the correctness of the program?

If the answer is yes, the design follows LSP.

Example

Suppose we have a Rectangle class where width and height can be changed independently. Then we create a Square class that inherits from Rectangle.

This violates LSP because a square requires width and height to always be equal. Code that expects a rectangle may set width and height independently, which breaks the behavior of the square.

ISP — Interface Segregation Principle

Clients should not be forced to depend on methods they do not use.

Instead of creating one large, general-purpose interface, create several smaller and more focused interfaces. This ensures that each client depends only on the functionality it actually needs.

DIP — Dependency Inversion Principle

Depend on abstractions, not concrete implementations.

High-level modules should not depend on low-level modules. Both should depend on abstractions.

The control flow is opposite to the dependency flow:

Control flow: Abstraction → Concrete implementation
Dependency flow: Concrete implementation → Abstraction

This allows business logic to remain independent of infrastructure details.

A common way to implement DIP is by using patterns such as Abstract Factory, Dependency Injection, or Inversion of Control (IoC).

https://refactoring.guru/design-patterns/abstract-factory

https://www.geeksforgeeks.org/system-design/dependency-injectiondi-design-pattern/

https://en.wikipedia.org/wiki/Inversion_of_control

For more information read the Robert Martin book: “Clean Architecture: A Craftsman's Guide to Software Structure and Design “

SOLID Principles