solid-srp-pattern

name	solid-srp-pattern
description	Implements the Single Responsibility Principle (SRP) from SOLID, ensuring a class has one reason to change.
license	MIT
compatibility	opencode
metadata	{"version":"1.0.0","domain":"architecture","triggers":"single responsibility principle, solid principles, gof patterns","archetypes":["educational"],"anti_triggers":["brainstorming","vague ideation"],"response_profile":{"verbosity":"low","directive_strength":"high","abstraction_level":"operational"},"role":"implementation","scope":"implementation","output-format":"code","related-skills":"solid-ocp-pattern,"}

Single Responsibility Principle (SRP)

archetypes: implementation, educational anti_triggers: multiple responsibilities response_profile: verbosity: medium directive_strength: high abstraction_level: tactical

Implements the Single Responsibility Principle from SOLID, ensuring a class has one reason to change.

When to Use

This section should succinctly explain the scenarios where the Single Responsibility Principle is applicable:

Archetypes

• Implementation: This skill aims to guide users in following the Single Responsibility Principle.
• Educational: Offers educational insights to users looking to understand SRP better.

Anti-Triggers

• Multiple responsibilities: Avoid context where classes or modules are expected to handle multiple concerns at once without separation.

Response Profile

• Verbosity: Medium

• Directive Strength: High

• Abstraction Level: Tactical

• When you want to ensure that a class or module has a single responsibility.

• To improve the maintainability and understandability of the code.

• When making changes to a class, ensuring impacts are minimized.

Core Workflow

1. Identify Responsibilities: Analyze what duties or functionalities can be performed by a class.
2. Refactor into Separate Classes: Create separate classes for each responsibility identified.
3. Apply Changes Incrementally: Adjust code to utilize new classes and methods appropriately.

Implementation Patterns

SRP Example

package main

import (
    "fmt"
)

// User represents a user model
type User struct {
    Name  string
    Email string
}

// UserRepository handles user-related database operations
type UserRepository struct {}

func (UserRepository) Save(u User) {
    // Logic to save user to database
    fmt.Println("Saving user:", u)
}

// EmailService manages email notifications
type EmailService struct {}

func (EmailService) SendEmail(email string, message string) {
    // Logic to send email
    fmt.Println("Sending email to:", email, "Message:", message)
}

Example Usage

package main

func main() {
    userRepo := UserRepository{}
    emailService := EmailService{}

    user := User{Name: "John Doe", Email: "[e-mail]"}
    userRepo.Save(user)
    emailService.SendEmail(user.Email, "Welcome to our service!")
}

Constraints

MUST DO

• Create distinct classes for each responsibility without merging functionalities.
• Clearly indicate the main responsibility of each class or module.

MUST NOT DO

• Allow any class to handle multiple responsibilities.
• Mix business logic with infrastructure concerns in one class.