Token导航 LogoToken导航TokenDH.com
研究检索需要联网github未标认证来源可访问clear审计未展示

solid-principles扎实的原则

Agent Skill

solid-principles 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

190

周安装

8

GitHub Stars

公开资料未说明

下载量

67
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:solid-principles(扎实的原则)
来源仓库:https://github.com/doubleslashse/claude-marketplace
仓库路径:skills/solid-principles
安装命令:
npx skills add doubleslashse/claude-marketplace --skill "solid-principles"
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

AgentSkills.tonpx skills
npx skills add doubleslashse/claude-marketplace --skill "solid-principles"

简介

用于发现并安装 AI 代理的技能,支持多宿主环境集成。

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中扩展 Agent 能力时使用。
  • 通过 npx 命令添加指定仓库路径下的技能模块即可快速部署。
  • 安装前应检查仓库维护状态及是否涉及敏感操作权限。
  • 该技能本身不包含具体业务逻辑,仅为技能管理工具。

SKILL.md

SOLID Principles for.NET

Overview

SOLID is an acronym for five principles that lead to maintainable, testable, and extensible object-oriented code.

PrincipleSummary
S - Single ResponsibilityOne class, one reason to change
O - Open/ClosedOpen for extension, closed for modification
L - Liskov SubstitutionSubtypes must be substitutable for base types
I - Interface SegregationMany specific interfaces > one general interface
D - Dependency InversionDepend on abstractions, not concretions

S - Single Responsibility Principle (SRP)

A class should have only one reason to change.

Violation Example

// BAD: Multiple responsibilities
public class OrderService
{
    public Order CreateOrder(OrderRequest request)
    {
        // Validation logic
        if (string.IsNullOrEmpty(request.CustomerEmail))
            throw new ValidationException("Email required");

        // Business logic
        var order = new Order
        {
            Id = Guid.NewGuid(),
            Items = request.Items,
            Total = CalculateTotal(request.Items)
        };

        // Persistence logic
        using var connection = new SqlConnection(_connectionString);
        connection.Execute("INSERT INTO Orders...", order);

        // Notification logic
        var emailBody = $"Order {order.Id} confirmed!";
        _smtpClient.Send(request.CustomerEmail, "Order Confirmed", emailBody);

        // Logging logic
        File.AppendAllText("orders.log", $"{DateTime.Now}: Order {order.Id} created");

        return order;
    }
}

Correct Implementation

// GOOD: Single responsibility per class
public class OrderService
{
    private readonly IOrderValidator _validator;
    private readonly IOrderRepository _repository;
    private readonly IOrderNotifier _notifier;
    private readonly ILogger<OrderService> _logger;

    public OrderService(
        IOrderValidator validator,
        IOrderRepository repository,
        IOrderNotifier notifier,
        ILogger<OrderService> logger)
    {
        _validator = validator;
        _repository = repository;
        _notifier = notifier;
        _logger = logger;
    }

    public async Task<Order> CreateOrderAsync(OrderRequest request)
    {
        _validator.Validate(request);

        var order = Order.Create(request.Items);

        await _repository.AddAsync(order);
        await _notifier.NotifyOrderCreatedAsync(order, request.CustomerEmail);

        _logger.LogInformation("Order {OrderId} created", order.Id);

        return order;
    }
}

// Each concern in its own class
public class OrderValidator : IOrderValidator
{
    public void Validate(OrderRequest request)
    {
        if (string.IsNullOrEmpty(request.CustomerEmail))
            throw new ValidationException("Email required");
    }
}

public class OrderRepository : IOrderRepository
{
    private readonly DbContext _context;

    public async Task AddAsync(Order order)
    {
        _context.Orders.Add(order);
        await _context.SaveChangesAsync();
    }
}

public class EmailOrderNotifier : IOrderNotifier
{
    private readonly IEmailService _emailService;

    public async Task NotifyOrderCreatedAsync(Order order, string email)
    {
        await _emailService.SendAsync(email, "Order Confirmed", $"Order {order.Id} confirmed!");
    }
}

SRP Test: Ask These Questions

  1. Can I describe what the class does without using "and"?
  2. Would different stakeholders want changes to this class?
  3. Does the class have more than 200-300 lines?

O - Open/Closed Principle (OCP)

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

Violation Example

// BAD: Must modify class to add new discount types
public class DiscountCalculator
{
    public decimal Calculate(Order order, string discountType)
    {
        switch (discountType)
        {
            case "percentage":
                return order.Total * 0.1m;
            case "fixed":
                return 10m;
            case "loyalty":
                return order.Total * 0.15m;
            // Every new discount requires modifying this class
            default:
                return 0m;
        }
    }
}

Correct Implementation

// GOOD: Extensible without modification
public interface IDiscountStrategy
{
    decimal Calculate(Order order);
}

public class PercentageDiscount : IDiscountStrategy
{
    private readonly decimal _percentage;

    public PercentageDiscount(decimal percentage) => _percentage = percentage;

    public decimal Calculate(Order order) => order.Total * _percentage;
}

public class FixedDiscount : IDiscountStrategy
{
    private readonly decimal _amount;

    public FixedDiscount(decimal amount) => _amount = amount;

    public decimal Calculate(Order order) => Math.Min(_amount, order.Total);
}

public class LoyaltyDiscount : IDiscountStrategy
{
    private readonly ILoyaltyService _loyaltyService;

    public LoyaltyDiscount(ILoyaltyService loyaltyService) => _loyaltyService = loyaltyService;

    public decimal Calculate(Order order)
    {
        var tier = _loyaltyService.GetCustomerTier(order.CustomerId);
        return tier switch
        {
            LoyaltyTier.Gold => order.Total * 0.15m,
            LoyaltyTier.Silver => order.Total * 0.10m,
            _ => 0m
        };
    }
}

// New discounts added without touching existing code
public class BulkDiscount : IDiscountStrategy
{
    public decimal Calculate(Order order)
    {
        if (order.Items.Count >= 10)
            return order.Total * 0.20m;
        return 0m;
    }
}

// Calculator is closed for modification
public class DiscountCalculator
{
    public decimal Calculate(Order order, IDiscountStrategy strategy)
    {
        return strategy.Calculate(order);
    }
}

OCP Patterns

  • Strategy Pattern (as shown above)
  • Template Method Pattern
  • Decorator Pattern
  • Plugin Architecture

L - Liskov Substitution Principle (LSP)

Objects of a superclass should be replaceable with objects of its subclasses without breaking the application.

Violation Example

// BAD: Square violates Rectangle's contract
public class Rectangle
{
    public virtual int Width { get; set; }
    public virtual int Height { get; set; }

    public int CalculateArea() => Width * Height;
}

public class Square : Rectangle
{
    public override int Width
    {
        get => base.Width;
        set
        {
            base.Width = value;
            base.Height = value; // Unexpected side effect!
        }
    }

    public override int Height
    {
        get => base.Height;
        set
        {
            base.Height = value;
            base.Width = value; // Unexpected side effect!
        }
    }
}

// This test fails for Square!
[Fact]
public void Rectangle_SetDimensions_CalculatesCorrectArea()
{
    Rectangle rect = new Square(); // Substitution
    rect.Width = 5;
    rect.Height = 4;
    Assert.Equal(20, rect.CalculateArea()); // Fails! Returns 16
}

Correct Implementation

// GOOD: Separate abstractions
public interface IShape
{
    int CalculateArea();
}

public class Rectangle : IShape
{
    public int Width { get; }
    public int Height { get; }

    public Rectangle(int width, int height)
    {
        Width = width;
        Height = height;
    }

    public int CalculateArea() => Width * Height;
}

public class Square : IShape
{
    public int Side { get; }

    public Square(int side) => Side = side;

    public int CalculateArea() => Side * Side;
}

// Both work correctly with the abstraction
public class AreaCalculator
{
    public int TotalArea(IEnumerable<IShape> shapes)
    {
        return shapes.Sum(s => s.CalculateArea());
    }
}

LSP Rules

  1. Preconditions cannot be strengthened in subtype
  2. Postconditions cannot be weakened in subtype
  3. Invariants must be preserved in subtype
  4. History constraint (no unexpected state changes)

Common LSP Violations

// BAD: Throwing NotSupportedException
public class ReadOnlyCollection<T> : ICollection<T>
{
    public void Add(T item) => throw new NotSupportedException();
}

// BAD: Ignoring base class behavior
public class CachedRepository : Repository
{
    public override void Save(Entity entity)
    {
        // Doesn't call base.Save() - breaks persistence!
        _cache.Add(entity);
    }
}

I - Interface Segregation Principle (ISP)

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

Violation Example

// BAD: Fat interface
public interface IWorker
{
    void Work();
    void Eat();
    void Sleep();
    void AttendMeeting();
    void WriteCode();
    void ManageTeam();
}

// Robot can't eat or sleep!
public class Robot : IWorker
{
    public void Work() { /* OK */ }
    public void Eat() => throw new NotSupportedException();
    public void Sleep() => throw new NotSupportedException();
    public void AttendMeeting() => throw new NotSupportedException();
    public void WriteCode() { /* OK */ }
    public void ManageTeam() => throw new NotSupportedException();
}

Correct Implementation

// GOOD: Segregated interfaces
public interface IWorkable
{
    void Work();
}

public interface IFeedable
{
    void Eat();
}

public interface ISleepable
{
    void Sleep();
}

public interface IMeetingAttendee
{
    void AttendMeeting();
}

public interface IDeveloper : IWorkable
{
    void WriteCode();
}

public interface IManager : IWorkable, IMeetingAttendee
{
    void ManageTeam();
}

// Clean implementations
public class HumanDeveloper : IDeveloper, IFeedable, ISleepable
{
    public void Work() { }
    public void WriteCode() { }
    public void Eat() { }
    public void Sleep() { }
}

public class Robot : IDeveloper
{
    public void Work() { }
    public void WriteCode() { }
    // No forced empty implementations!
}

Repository ISP Example

// BAD: Monolithic repository
public interface IRepository<T>
{
    T GetById(int id);
    IEnumerable<T> GetAll();
    void Add(T entity);
    void Update(T entity);
    void Delete(T entity);
    IEnumerable<T> Find(Expression<Func<T, bool>> predicate);
    void BulkInsert(IEnumerable<T> entities);
    void ExecuteRawSql(string sql);
}

// GOOD: Segregated repositories
public interface IReadRepository<T>
{
    T? GetById(int id);
    IEnumerable<T> GetAll();
}

public interface IWriteRepository<T>
{
    void Add(T entity);
    void Update(T entity);
    void Delete(T entity);
}

public interface IQueryRepository<T>
{
    IEnumerable<T> Find(Expression<Func<T, bool>> predicate);
}

// Compose as needed
public interface IOrderRepository : IReadRepository<Order>, IWriteRepository<Order> { }

public interface IReportRepository : IReadRepository<Report>, IQueryRepository<Report> { }

D - Dependency Inversion Principle (DIP)

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

Violation Example

// BAD: High-level depends on low-level
public class OrderService
{
    private readonly SqlOrderRepository _repository; // Concrete!
    private readonly SmtpEmailSender _emailSender;   // Concrete!

    public OrderService()
    {
        _repository = new SqlOrderRepository("connection-string");
        _emailSender = new SmtpEmailSender("smtp.server.com");
    }

    public void CreateOrder(Order order)
    {
        _repository.Save(order);
        _emailSender.Send(order.CustomerEmail, "Order Created");
    }
}

Correct Implementation

// GOOD: Depend on abstractions
public interface IOrderRepository
{
    Task SaveAsync(Order order);
    Task<Order?> GetByIdAsync(Guid id);
}

public interface INotificationService
{
    Task SendAsync(string recipient, string subject, string message);
}

public class OrderService
{
    private readonly IOrderRepository _repository;
    private readonly INotificationService _notificationService;

    // Dependencies injected via constructor
    public OrderService(
        IOrderRepository repository,
        INotificationService notificationService)
    {
        _repository = repository;
        _notificationService = notificationService;
    }

    public async Task CreateOrderAsync(Order order)
    {
        await _repository.SaveAsync(order);
        await _notificationService.SendAsync(
            order.CustomerEmail,
            "Order Created",
            $"Your order {order.Id} has been created.");
    }
}

// Low-level modules implement abstractions
public class SqlOrderRepository : IOrderRepository
{
    private readonly DbContext _context;

    public SqlOrderRepository(DbContext context) => _context = context;

    public async Task SaveAsync(Order order)
    {
        _context.Orders.Add(order);
        await _context.SaveChangesAsync();
    }

    public async Task<Order?> GetByIdAsync(Guid id)
    {
        return await _context.Orders.FindAsync(id);
    }
}

public class EmailNotificationService : INotificationService
{
    private readonly IEmailClient _emailClient;

    public EmailNotificationService(IEmailClient emailClient) => _emailClient = emailClient;

    public async Task SendAsync(string recipient, string subject, string message)
    {
        await _emailClient.SendEmailAsync(recipient, subject, message);
    }
}

// Registration in DI container
services.AddScoped<IOrderRepository, SqlOrderRepository>();
services.AddScoped<INotificationService, EmailNotificationService>();
services.AddScoped<OrderService>();

DIP Benefits

  1. Testability: Mock dependencies easily
  2. Flexibility: Swap implementations without changing consumers
  3. Maintainability: Changes isolated to implementations
  4. Parallel development: Teams work on interfaces

Quick Reference

PrincipleViolation SignFix
SRPClass has multiple reasons to changeExtract classes by responsibility
OCPAdding features requires modifying existing codeUse abstractions and composition
LSPSubclass can't substitute base classFix inheritance or use composition
ISPImplementations throw NotSupportedSplit large interfaces
DIPHigh-level creates low-level instancesInject dependencies via interfaces

See examples.md for more comprehensive examples.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

windsurf

29.11%
按下载量换算20

OpenCode

19.95%
按下载量换算13

Codex

17.68%
按下载量换算12

Claude Code

12.3%
按下载量换算8

Antigravity

7.08%
按下载量换算5

Gemini CLI

3.36%
按下载量换算2

安全审计

暂无安全审计结果可展示。

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills