个人笔记

站长信息

jeffery.xu

软件工程师

欢迎访问我的个人笔记网站！我是一名热爱技术的开发者，专注于Web开发和技术分享。

811495111@qq.com

18521510875

欢迎访问我的笔记

筛选

搜索

分类

标签

软考新框架form 新框架小技巧网站经验生活经验设计模式 C#本质论工作记录明末计划总结 java学习英语

懒汉式单实例

设计模式

public class Singleton
{
private static Singleton instance;
private static readonly object lockObj = new object();

private Singleton() { }

public static Singleton Instance
{
get
{
if (instance == null)
{
lock (lockObj)
{
if (instance == null)
{
instance = new Singleton();
}
}
}
return instance;
}
}
}

2025-08-29

设计模式

查看

工厂模式

设计模式

工厂模式是一种创建对象的设计模式，它将对象的创建和使用分离，使得代码更加灵活、可维护和可扩展。这种模式特别适用于以下场景：

当一个类不知道它所必须创建的对象的类时
当一个类希望由它的子类来指定所创建的对象时

当将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化时

using System;

// 定义产品接口
public interface IProduct
{
    void Operation();
}

// 具体产品A
public class ConcreteProductA : IProduct
{
    public void Operation()
    {
        Console.WriteLine("ConcreteProductA Operation");
    }
}

// 具体产品B
public class ConcreteProductB : IProduct
{
    public void Operation()
    {
        Console.WriteLine("ConcreteProductB Operation");
    }
}

// 简单工厂类
public class SimpleFactory
{
    public static IProduct CreateProduct(string type)
    {
        switch (type.ToLower())
        {
            case "a":
                return new ConcreteProductA();
            case "b":
                return new ConcreteProductB();
            default:
                throw new ArgumentException("Invalid product type", nameof(type));
        }
    }
}

// 客户端代码
class Program
{
    static void Main()
    {
        // 使用简单工厂创建产品A
        IProduct productA = SimpleFactory.CreateProduct("A");
        productA.Operation();

        // 使用简单工厂创建产品B
        IProduct productB = SimpleFactory.CreateProduct("B");
        productB.Operation();

        try
        {
            // 尝试创建无效产品类型
            IProduct invalidProduct = SimpleFactory.CreateProduct("C");
            invalidProduct.Operation();
        }
        catch (ArgumentException ex)
        {
            Console.WriteLine($"Error: {ex.Message}");
        }
    }
}

工厂模式的优点

解耦对象的创建和使用：客户端不需要知道具体产品类的类名，只需要知道对应的参数即可。
可扩展性好：在增加新的产品类时，只需要修改工厂类或者扩展工厂子类，符合开闭原则。
便于代码维护：创建对象的逻辑集中在一个工厂类中，便于维护和修改。

工厂模式的缺点

工厂类职责过重：简单工厂模式中，工厂类集中了所有产品的创建逻辑，一旦不能正常工作，整个系统都会受到影响。
增加系统复杂度：如果产品种类过多，会导致工厂类变得庞大，增加系统的复杂度。
违反开闭原则：在简单工厂模式中，每当增加新的产品时，都需要修改工厂类，这违反了开闭原则。

工厂模式在实际开发中应用广泛，特别是在需要创建大量对象、对象创建过程复杂或者需要根据不同条件创建不同类型对象的场景中。

2025-07-25

设计模式

查看

依赖倒置原则（Dependency Inversion Principle, DIP）

设计模式

高层模块不应依赖低层模块，二者都应依赖抽象。

抽象不应依赖细节，细节应依赖抽象。
示例：

# 反例：高层模块依赖低层模块
class LightBulb:
    def turn_on(self):
        print("灯泡亮了")

class Switch:
    def __init__(self):
        self.bulb = LightBulb()  # 直接依赖具体实现

# 正例：依赖抽象
from abc import ABC, abstractmethod

class Switchable(ABC):
    @abstractmethod
    def turn_on(self):
        pass

class LightBulb(Switchable):
    def turn_on(self):
        print("灯泡亮了")

class Fan(Switchable):
    def turn_on(self):
        print("风扇转了")

class Switch:
    def __init__(self, device: Switchable):
        self.device = device  # 依赖抽象而非具体实现

2025-07-24

设计模式

查看

接口隔离原则（Interface Segregation Principle, ISP）

设计模式

客户端不应该被迫依赖它不需要的接口。应该把庞大的接口拆分成更小、更具体的接口。

# 反例：一个大而全的接口
class Worker:
    def work(self):
        pass
    def eat(self):
        pass

class Robot(Worker):
    def work(self):
        pass
    def eat(self):
        raise NotImplementedError("机器人不需要吃饭")  # 被迫实现不需要的方法

# 正例：拆分接口
class Workable:
    def work(self):
        pass

class Eatable:
    def eat(self):
        pass

class HumanWorker(Workable, Eatable):
    pass

class RobotWorker(Workable):
    pass

2025-07-23

软考设计模式

查看

里氏替换原则（Liskov Substitution Principle, LSP）

设计模式

里氏替换原则（Liskov Substitution Principle, LSP）是面向对象设计的核心原则之一，由芭芭拉・利斯科夫（Barbara Liskov）在 1987 年提出。其核心思想是：子类对象必须能够替换掉它们的父类对象，而不影响程序的正确性。这意味着，子类应当遵循父类的契约，保持行为的一致性。

核心动机

继承的正确性：确保子类不会破坏父类的原有功能。
多态的可靠性：通过父类引用调用子类方法时，结果应符合预期。
降低系统风险：避免因子类行为异常导致的潜在错误。

LSP 的关键要求

前置条件不能强化：子类方法的前置条件（输入参数）不能比父类更严格。
后置条件不能弱化：子类方法的后置条件（返回值）必须满足父类的要求。
不变式要保持：子类不能改变父类的不变量（如类的约束条件）。
异常要兼容：子类抛出的异常应当与父类一致或为其子类。

C# 示例：矩形与正方形问题

违反 LSP 的经典案例

假设我们有一个矩形类和一个正方形类，正方形继承自矩形：

// 基类：矩形
public class Rectangle
{
    public virtual double Width { get; set; }
    public virtual double Height { get; set; }

    public double Area() => Width * Height;
}

// 子类：正方形（错误设计）
public class Square : Rectangle
{
    // 正方形的宽和高必须相等
    public override double Width
    {
        get => base.Width;
        set
        {
            base.Width = value;
            base.Height = value;
        }
    }

    public override double Height
    {
        get => base.Height;
        set
        {
            base.Height = value;
            base.Width = value;
        }
    }
}

问题分析

这个设计违反了 LSP，因为：

前置条件被强化：父类允许设置不同的宽和高，但子类强制二者相等。

行为不一致：以下代码在使用父类时正常，但使用子类时会出错：

public void TestRectangle(Rectangle rect)
{
    rect.Width = 5;
    rect.Height = 10;
    Console.WriteLine(rect.Area()); // 预期输出50
}

// 测试
var rectangle = new Rectangle();
TestRectangle(rectangle); // 输出50，正确

var square = new Square();
TestRectangle(square);    // 输出100，错误！

遵循 LSP 的重构方案

方案 1：抽象公共接口

// 抽象接口：四边形
public interface IQuadrilateral
{
    double Width { get; }
    double Height { get; }
    double Area();
}

// 矩形实现
public class Rectangle : IQuadrilateral
{
    public double Width { get; set; }
    public double Height { get; set; }
    public double Area() => Width * Height;
}

// 正方形实现
public class Square : IQuadrilateral
{
    private double _side;
    
    public double Width
    {
        get => _side;
        set => _side = value;
    }
    
    public double Height
    {
        get => _side;
        set => _side = value;
    }
    
    public double Area() => _side * _side;
}

方案 2：组合而非继承

// 正方形包含一个矩形实例
public class Square
{
    private readonly Rectangle _rectangle = new Rectangle();
    
    public double Side
    {
        get => _rectangle.Width;
        set
        {
            _rectangle.Width = value;
            _rectangle.Height = value;
        }
    }
    
    public double Area() => _rectangle.Area();
}

另一个示例：银行账户与透支账户

违反 LSP 的设计

// 基类：银行账户
public class BankAccount
{
    protected double _balance;
    
    public virtual void Withdraw(double amount)
    {
        if (amount > _balance)
            throw new InvalidOperationException("余额不足");
        
        _balance -= amount;
    }
}

// 子类：透支账户（错误设计）
public class OverdraftAccount : BankAccount
{
    private double _overdraftLimit = 1000;
    
    // 重写取款方法，允许透支
    public override void Withdraw(double amount)
    {
        if (amount > _balance + _overdraftLimit)
            throw new InvalidOperationException("超过透支限额");
            
        _balance -= amount;
    }
}

问题分析

前置条件被弱化：子类允许更多情况下的取款（透支），而父类不允许。
行为不一致：依赖父类行为的代码（如检查余额）在使用子类时会失效。

LSP 的其他应用场景

集合类中的协变与逆变：确保泛型集合的类型安全。
事件处理：子类事件的参数应与父类兼容。
数据库操作：子类的查询条件不能比父类更严格。

总结

LSP 是继承的契约：子类必须遵守父类的行为约定。
避免破坏父类行为：重写方法时不要改变原有的语义。
优先使用组合：当继承导致 LSP 违反时，考虑使用组合或接口替代。

通过遵循 LSP，代码可以保持良好的可替换性和扩展性，降低系统的耦合度。

2025-07-21

软考设计模式

查看

开闭原则（Open/Closed Principle, OCP）

设计模式

开闭原则（Open/Closed Principle, OCP）是面向对象设计的核心原则之一，由 Bertrand Meyer 提出。其核心思想是：软件实体（类、模块、函数等）应当对扩展开放，对修改关闭。这意味着在添加新功能时，应该通过扩展现有代码而非修改它来实现。

核心动机

减少风险：修改现有代码可能引入新的错误，影响原有功能。
提高可维护性：代码无需频繁修改，降低维护成本。
促进复用：通过抽象和多态，可复用现有设计框架。

实现方式

抽象化：通过接口或抽象类定义稳定的契约。
多态：利用子类实现行为的扩展。
依赖注入：通过依赖倒置，使高层模块不依赖具体实现。

C# 示例：报表生成器

假设你正在开发一个报表生成器，初始需求是生成 PDF 报表。随着业务发展，需要支持 Excel 和 CSV 格式。

public class ReportGenerator
{
    public void GenerateReport(string format, ReportData data)
    {
        if (format == "PDF")
        {
            // 生成 PDF 报表的具体实现
            Console.WriteLine("生成 PDF 报表");
        }
        else if (format == "Excel")
        {
            // 生成 Excel 报表的具体实现
            Console.WriteLine("生成 Excel 报表");
        }
        // 问题：每次新增格式都需要修改此方法
    }
}

遵循开闭原则的重构

通过抽象化和多态，将报表生成逻辑封装到独立的类中：

// 定义报表生成器接口（抽象）
public interface IReportGenerator
{
    void Generate(ReportData data);
}

// 具体实现：PDF 报表生成器
public class PdfReportGenerator : IReportGenerator
{
    public void Generate(ReportData data)
    {
        Console.WriteLine("生成 PDF 报表");
    }
}

// 具体实现：Excel 报表生成器
public class ExcelReportGenerator : IReportGenerator
{
    public void Generate(ReportData data)
    {
        Console.WriteLine("生成 Excel 报表");
    }
}

// 新增格式：CSV 报表生成器（无需修改原有代码）
public class CsvReportGenerator : IReportGenerator
{
    public void Generate(ReportData data)
    {
        Console.WriteLine("生成 CSV 报表");
    }
}

// 报表服务：依赖抽象接口
public class ReportService
{
    private readonly IReportGenerator _generator;

    public ReportService(IReportGenerator generator)
    {
        _generator = generator; // 通过构造函数注入依赖
    }

    public void CreateReport(ReportData data)
    {
        _generator.Generate(data);
    }
}

// 使用示例
public class Program
{
    public static void Main()
    {
        var data = new ReportData();
        
        // 需要 PDF 报表时
        var pdfService = new ReportService(new PdfReportGenerator());
        pdfService.CreateReport(data);

        // 需要 Excel 报表时
        var excelService = new ReportService(new ExcelReportGenerator());
        excelService.CreateReport(data);

        // 需要 CSV 报表时（扩展无需修改原有代码）
        var csvService = new ReportService(new CsvReportGenerator());
        csvService.CreateReport(data);
    }
}

关键改进点

抽象化：通过 IReportGenerator 接口定义稳定的报表生成契约。
多态：每个报表格式（PDF/Excel/CSV）都实现该接口，行为由具体子类决定。
依赖注入：ReportService 依赖接口而非具体实现，支持动态切换报表生成器。

新增需求：添加 HTML 报表

若需新增 HTML 报表，只需：

创建 HtmlReportGenerator 类实现 IReportGenerator。
在调用处注入新的生成器，无需修改现有类。
```
public class HtmlReportGenerator : IReportGenerator
{
    public void Generate(ReportData data)
    {
        Console.WriteLine("生成 HTML 报表");
    }
}

// 使用时直接注入新实现
var htmlService = new ReportService(new HtmlReportGenerator());
htmlService.CreateReport(data);
```
开闭原则的其他应用场景
1. 插件系统：通过接口定义插件规范，新插件只需实现接口。
2. 策略模式：将算法封装为策略类，运行时动态切换。
3. 事件驱动架构：通过事件和监听器实现功能扩展。
注意事项
- 过度抽象风险：不要为未来可能的需求过度设计，遵循 YAGNI（You Aren't Gonna Need It）原则。
- 平衡点：对可能变化的部分应用 OCP，对稳定部分无需过度抽象。
通过开闭原则，代码可以优雅地应对变化，同时保持稳定性和可维护性。

2025-07-20

软考设计模式

查看

站长信息

jeffery.xu

筛选

热门标签

个人笔记

懒汉式单实例

工厂模式

工厂模式的优点

工厂模式的缺点

依赖倒置原则（Dependency Inversion Principle, DIP）

接口隔离原则（Interface Segregation Principle, ISP）

里氏替换原则（Liskov Substitution Principle, LSP）

核心动机

LSP 的关键要求

C# 示例：矩形与正方形问题

违反 LSP 的经典案例

问题分析

遵循 LSP 的重构方案

方案 1：抽象公共接口

方案 2：组合而非继承

另一个示例：银行账户与透支账户

违反 LSP 的设计

问题分析

LSP 的其他应用场景

总结

开闭原则（Open/Closed Principle, OCP）

核心动机

实现方式

C# 示例：报表生成器

遵循开闭原则的重构

关键改进点

新增需求：添加 HTML 报表

开闭原则的其他应用场景

注意事项