SOLID Principles Evaluation

This lesson shows an automated SOLID principles audit run against an Express.js application (Express Login Demo). The audit identifies common anti‑patterns (monolithic handlers, hardcoded dependencies, fat req/res usage, direct instantiation of low‑level resources, etc.) and produces a structured report with severity ratings and concrete remediation snippets you can drop into the codebase. Below are the command context used while running the audit, trimmed audit prompt, a concise overview of the SOLID principles, a summary of how the audit checks each principle, an executive summary of the audit results, and targeted, code-level remediation examples that make the fixes incremental and testable. Command context shown while running the audit:

cwd: /Users/jeremy/Repos/[Claude Code for Beginners](https://learn.kodekloud.com/user/courses/claude-code-for-beginners)/Express-login-demo

What's new:
• Fixed issue causing "OAuth authentication is currently not supported"
• Status line input now includes `exceeds_200k_tokens`
• Fixed incorrect usage tracking in /cost.
• Introduced `ANTHROPIC_DEFAULT_SONNET_MODEL` and `ANTHROPIC_DEFAULT_OPUS_MODEL` for controlling model aliases opusplan, opus, and sonnet.
• Bedrock: Updated default Sonnet model to Sonnet 4

> Try `how does <filepath> work?`

? for shortcuts

Audit prompt (trimmed to essentials used for the SOLID check):

4. INTERFACE SEGREGATION
– Are interfaces too large?
– Do clients depend on methods they don't use?

5. DEPENDENCY INVERSION
– Are we depending on abstractions or concretions?
– Is there proper dependency injection?
– Check for 'new' keyword usage vs injection

Rate SOLID compliance (1–10) with specific violations and fixes.

## Provide:

A structured finding report
A scale of 1/10 on how important each finding is
Remediation: precise code-level fix or config change (snippets welcome)

## Constraints & style:

Be concrete and cite exact code locations and identifiers.
Prefer minimal, drop-in fix snippets over prose.
Do not invent files or functions that aren't present; if context is missing, mark as Unable to verify and say what code would prove it.
Write this into a markdown file and place it in the audits/ folder.

• I'll evaluate this Express application's adherence to SOLID principles by analyzing the codebase structure and implementation.

Overview — SOLID principles (concise)

Principle	Short definition	Focus during audit
Single Responsibility Principle (SRP)	A module/class should have one reason to change.	Look for functions handling validation, DB access, crypto, token generation, and response formatting together.
Open/Closed Principle (OCP)	Open for extension, closed for modification.	Identify switch/if chains and hardcoded conditionals that require changing core logic to add behavior.
Liskov Substitution Principle (LSP)	Subtypes should be usable wherever the base type is expected.	Look for direct instantiation that prevents substituting mocks or alternate implementations.
Interface Segregation Principle (ISP)	Clients shouldn’t depend on methods they don’t use.	Check for handlers relying on full `req`/`res` instead of the minimal inputs/outputs.
Dependency Inversion Principle (DIP)	High-level modules depend on abstractions, not concretes.	Detect `require`/`new` of low-level modules inside high-level code and direct `process.env` usage.

How the audit checks each principle (summary)

SRP: Detects functions or files doing multiple distinct tasks (validation, DB access, encryption, token creation, response shaping).
OCP: Flags switch/if chains and centralized conditionals that must change to add features.
LSP: Looks for concrete new/require usage inside higher-level modules (routes/services), blocking substitutability.
ISP: Finds handlers that accept whole Express req/res objects while using only a subset of fields.
DIP: Scans for direct instantiation and process.env use inside business logic rather than injected config/abstractions.

Executive summary

Application: Express Login Demo
Overall SOLID Compliance Score: 4/10
Main issues found:
- Monolithic route handlers that combine validation, DB calls, crypto, and token creation.
- Hardcoded dependencies: DB client, crypto libs, JWT usage, and process.env reads embedded in logic.
- Lack of clear abstraction layers (repository pattern, service interfaces).
- Fat req/res usage making handlers tightly coupled to Express.
Priority remediation: Extract auth service, introduce repository abstractions, centralize configuration, and create pluggable auth strategies.

Detailed findings and concrete remediation

Single Responsibility Principle (SRP)

Violation: Monolithic auth route handler performing validation, DB access, password checks, JWT generation, and response formatting.
Location: routes/auth.js (e.g., /login route, lines ~17–96)
Severity: HIGH (9/10)
Why: Multiple concerns are combined into a single function, increasing fragility and reducing testability.

Current pattern (anti-pattern):

// routes/auth.js (current anti-pattern)
router.post('/login', async (req, res) => {
  // 1. Validate req.body
  // 2. Query DB for user
  // 3. Compare password with bcrypt
  // 4. Generate JWT
  // 5. Send response or error
});

Remediation — split responsibilities:

// services/authService.js
const bcrypt = require('bcrypt'); // consider replacing with a crypto abstraction in future
module.exports = function createAuthService(userRepository, jwtService, config) {
  return {
    async authenticate(email, password) {
      const user = await userRepository.findByEmail(email);
      if (!user) return null;
      const match = await bcrypt.compare(password, user.password_hash);
      if (!match) return null;
      return { user, token: jwtService.generateToken({ id: user.id, email: user.email }) };
    }
  };
};

Thin route using injected service:

// routes/auth.js (thin route)
const authService = createAuthService(userRepository, jwtService, config);
router.post('/login', async (req, res, next) => {
  try {
    const result = await authService.authenticate(req.body.email, req.body.password);
    if (!result) return res.status(401).json({ error: 'Invalid credentials' });
    res.json({ token: result.token, user: result.user });
  } catch (err) {
    next(err);
  }
});

Open/Closed Principle (OCP)

Violation: Error handling via switch statements or centralized if chains that require editing core logic to add new error types.
Severity: MEDIUM–HIGH (7/10)

Current anti-pattern:

// Example problematic code
switch (error.code) {
  case 'ECONNREFUSED':
    return res.status(503).json({ error: 'Database connection failed' });
  case '28P01':
    return res.status(503).json({ error: 'Database authentication failed' });
  // Adding new error handling requires editing this switch
}

Remediation — handler map/strategy:

// services/errorHandlers.js
const errorHandlers = {
  'ECONNREFUSED': () => ({ status: 503, body: { error: 'Database connection failed' } }),
  '28P01': () => ({ status: 503, body: { error: 'Database authentication failed' } }),
};

function handleDatabaseError(error) {
  const handler = errorHandlers[error.code] || (() => ({ status: 500, body: { error: 'Database error occurred' } }));
  return handler();
}
module.exports = { handleDatabaseError, errorHandlers };

To extend handling, add a new key to errorHandlers instead of editing control flow.

Liskov Substitution Principle (LSP)

Violation: Direct instantiation of DB pool inside route modules prevents substituting mocks or alternative implementations.
Location example: routes/auth.js contains const pool = require('../config/database');
Severity: MEDIUM (6/10)

Remediation — inject a repository abstraction: Repository interface (documentation-style class):

// repositories/userRepository.js (interface-like)
class UserRepository {
  async findByEmail(email) { throw new Error('Must implement findByEmail'); }
}
module.exports = UserRepository;

Concrete implementation:

// repositories/postgresUserRepository.js
const UserRepository = require('./userRepository');
class PostgresUserRepository extends UserRepository {
  constructor(pool) {
    super();
    this.pool = pool;
  }
  async findByEmail(email) {
    const result = await this.pool.query('SELECT * FROM users WHERE email = $1', [email]);
    return result.rows[0];
  }
}
module.exports = PostgresUserRepository;

Inject PostgresUserRepository in production; tests can inject a MockUserRepository.

Interface Segregation Principle (ISP)

Violation: Route handlers depend on full Express req/res objects, though only a few fields are used.
Severity: MEDIUM (6/10)

Remediation — pass minimal inputs and a response handler:

// handlers/loginHandler.js
async function loginHandler({ email, password }, responseHandler, services) {
  const { authService } = services;
  const result = await authService.authenticate(email, password);
  if (!result) return responseHandler.unauthorized({ error: 'Invalid credentials' });
  responseHandler.ok({ token: result.token, user: result.user });
}
module.exports = loginHandler;

Usage in route:

router.post('/login', (req, res, next) => {
  const credentials = { email: req.body.email, password: req.body.password };
  const responseHandler = {
    ok: (data) => res.json(data),
    unauthorized: (data) => res.status(401).json(data),
    error: (status, data) => res.status(status).json(data)
  };
  loginHandler(credentials, responseHandler, { authService }).catch(next);
});

Dependency Inversion Principle (DIP)

Violation: High-level auth logic depends on low-level modules (DB pool, bcrypt, jsonwebtoken, process.env), making swapping implementations or mocking in tests difficult.
Location examples: routes/auth.js importing DB connection; services directly requiring bcrypt or jsonwebtoken; business logic reading process.env.JWT_SECRET.
Severity: CRITICAL (10/10) for direct DB dependency; HIGH for env/crypto dependency.

Remediation — extract and inject abstractions: Config abstraction:

// services/configService.js
class Config {
  constructor(env = process.env) {
    this.env = env;
  }
  get jwtSecret() { return this.env.JWT_SECRET; }
  get jwtExpiresIn() { return this.env.JWT_EXPIRES_IN || '24h'; }
}
module.exports = Config;

JWT service abstraction:

// services/jwtService.js
const jwt = require('jsonwebtoken');
module.exports = function createJwtService(config) {
  return {
    generateToken(payload) {
      return jwt.sign(payload, config.jwtSecret, { expiresIn: config.jwtExpiresIn });
    }
  };
};

Crypto abstraction:

// services/cryptoService.js
const bcrypt = require('bcrypt');
module.exports = {
  compare: (plain, hash) => bcrypt.compare(plain, hash),
  hash: (plain) => bcrypt.hash(plain, 10)
};

Inject these dependencies into authService or controllers rather than requiring them directly inside business logic. Example controller wiring:

// controllers/authController.js
module.exports = function createAuthController({ userRepository, jwtService, cryptoService, config }) {
  return {
    async login(email, password) {
      const user = await userRepository.findByEmail(email);
      if (!user) return null;
      const ok = await cryptoService.compare(password, user.password_hash);
      if (!ok) return null;
      const token = jwtService.generateToken({ id: user.id, email: user.email });
      return { user, token };
    }
  };
};

Priority remediation plan (phased, practical)

Phase	Priority	Actions
Phase 1 — Critical (immediate)	High	Extract Authentication Service; Implement Repository Pattern; Create Config Service to encapsulate `process.env`.
Phase 2 — High	High	Implement Error Handler Strategy (map-based); Extract JWT & Crypto services; Add Validation Service (middleware).
Phase 3 — Medium	Medium	Implement pluggable authentication strategies (local, OAuth); Introduce a service container / startup wiring file; Add interface documentation and mocks for testing.

Code quality metrics observed (examples)

Cyclomatic complexity: High (login function had 8+ decision points).
Lines per function: Large (login function ~79 lines).
Coupling: High (routes directly require DB, crypto, jwt).
Testability: Poor (no DI; direct env and DB usage).

Run the SOLID audit early and often. Make controllers/routes thin and move logic into services that accept injected collaborators (repositories, crypto, jwt, config). This maximizes testability and extensibility while yielding quick return on refactoring efforts.

Related artifacts and resources

The audit tool generated a markdown report (example above) and suggested an architecture:
- controllers/authController.js (thin routing layer)
- services/authService.js, jwtService.js, configService.js
- repositories/userRepository.js (+ concrete DB implementations)
- strategies/authStrategies.js
- middleware/validation.js, middleware/errorHandler.js

A dark‑mode screenshot of a GitHub repository page showing a list of markdown files for security and code‑review topics (e.g., input validation, database and session cookie security). The right side shows repository details and metadata.

Where to get the prompts used for these audits:

https://github.com/JeremyMorgan/Claude-Code-Reviewing-Prompts

Next steps for your project (practical checklist)

Extract login logic into an authService and inject userRepository and jwtService.
Replace direct process.env reads with a configService that can be overridden in tests.
Replace require/new of DB/crypto in routes with injected abstractions.
Introduce small utility modules (jwtService, cryptoService, errorHandlers) and wire them centrally in a startup file.

Final assessment (concise)

The codebase has a working authentication flow but demonstrates strong coupling and several SOLID violations. Start with dependency inversion and single responsibility refactors: extract services, use repository abstractions, and centralize configuration. Those changes will immediately improve testability, reduce coupling, and make the codebase easier to extend without modifying core logic.

Introduction

Getting Started with Claude Code

Working with Claude Code

Code Review with Claude Code

Security Auditing with Claude Code

Advanced Features

SOLID Principles Evaluation

Overview — SOLID principles (concise)

How the audit checks each principle (summary)

Executive summary

Detailed findings and concrete remediation

Priority remediation plan (phased, practical)

Code quality metrics observed (examples)

Watch Video

​Overview — SOLID principles (concise)

​How the audit checks each principle (summary)

​Executive summary

​Detailed findings and concrete remediation

​Priority remediation plan (phased, practical)

​Code quality metrics observed (examples)

Watch Video

Overview — SOLID principles (concise)

How the audit checks each principle (summary)

Executive summary

Detailed findings and concrete remediation

Priority remediation plan (phased, practical)

Code quality metrics observed (examples)