如何实现GoogleCalendarService与应用的松耦合？支持替换日历服务

这是个很好的问题，要实现松耦合同时支持后续替换其他日历服务，核心思路是依赖倒置原则——依赖抽象而非具体实现。咱们一步步来拆解实现方案：

首先创建一个抽象接口，把你业务中需要的日历操作都抽象出来，接口只关注「做什么」，不关心「怎么做」。这样后续任何日历服务只要实现这个接口，就能无缝替换：

public interface ICalendarService
{
    // 对应创建预约的操作
    void Create(Booking newBooking, string userId);
    // 对应获取事件列表的操作
    List<Booking> GetEvents();
}

修改你的GoogleCalendarService，让它实现上面定义的ICalendarService接口——原来的业务逻辑完全不用改，只需要添加接口实现的声明即可：

public class GoogleCalendarService : ICalendarService
{
    private const string CalendarId = ".....";
    
    private CalendarService Authenticate(string calendarId) { ... }
    
    // 实现接口的Create方法
    public void Create(Booking newBooking, string userId) 
    { 
        // 原有的创建逻辑保留
        ... 
        InsertEvent(newEvent, userId); 
    }
    
    private void Insert(Event newEvent, string userId) { ... }
    
    // 实现接口的GetEvents方法
    public List<Booking> GetEvents() 
    { 
        // 原有的获取事件逻辑保留
        ... 
    }
}

把原来直接new具体类的代码，改成通过构造函数注入接口实例。这样应用层完全不知道底层是Google日历还是其他服务，彻底实现松耦合：

public class MyApplication
{
    // 依赖抽象接口，而非具体的GoogleCalendarService
    private readonly ICalendarService _calendarService;

    // 通过构造函数注入接口实例
    public MyApplication(ICalendarService calendarService)
    {
        _calendarService = calendarService ?? throw new ArgumentNullException(nameof(calendarService));
    }

    private void MyFunction()
    {
        // 调用接口方法，和具体实现完全解耦
        _calendarService.Create(..., ...);
    }
}

最后在应用启动时，用依赖注入容器（比如.NET自带的IServiceCollection）把接口和具体实现绑定：

// 示例：在Program.cs或Startup.cs中注册
services.AddScoped<ICalendarService, GoogleCalendarService>();

• 轻松替换服务：以后如果要换成Outlook或其他日历服务，只需要写一个OutlookCalendarService : ICalendarService，然后修改注册代码即可，应用业务逻辑完全不用动。
• 方便单元测试：可以写一个MockCalendarService : ICalendarService模拟接口方法，不用真的调用外部API就能测试应用逻辑。

内容的提问来源于stack exchange，提问作者user9855465