反模式 DI anti-patterns

反模式DI anti-patterns

《Dependency Injecttion Prinsciples,Practices, and Patterns》—— StevenVan Deursen and Mark Seemann

一、一、反模式 DI anti-patterns

1. 控制狂 Control freak

在程序设计中，"Control freak"（控制狂）通常指的是一种反模式，即过度控制和过度管理代码的设计和执行流程。这种情况下，程序员试图通过过度的控制和指令来达到对代码的绝对控制，而忽视了灵活性、可扩展性和可维护性。

控制狂在程序设计中可能表现为以下行为：

过度复杂的控制逻辑：设计过于复杂的控制逻辑，使得代码难以理解和维护。
过度使用全局状态：滥用全局变量或全局状态，使得代码之间的依赖关系变得混乱和难以追踪。
过度依赖条件语句：过多地使用条件语句（如if-else语句），导致代码逻辑分散、冗长和难以扩展。
过度使用硬编码：将具体数值、路径或配置直接硬编码到代码中，而不是使用配置文件或参数来实现灵活性。

这些行为会导致代码的可读性、可维护性和可扩展性下降，增加了代码的复杂性和脆弱性。相反，良好的程序设计应该追求简洁、模块化和松耦合的原则，以实现可维护、可扩展和易于理解的代码。

1-1. 示例：

        ... 
		private readonly IProductRepository _productRepository; 
 
        public ProductService() 
        { 
            //反模式范例，直接new一个SqlProductRepository，导致紧耦合 
            _productRepository = new SqlProductRepository(); 
        } 
		... 

1-2. 工厂模式下的反模式

实体工厂可以解决一些复杂物件建立逻辑封装在工厂中，可以避免写重复的代码。但是在DI架构下，工厂模式没有带来益处。

    public  class ProductRepositoryFactory 
    { 
        public static IProductRepository CreateProductRepository() 
        { 
            //工厂模式反模式范例，程序变复杂，只是控制狂换了个位置 
            return new SqlProductRepository(); 
        } 
    } 

即便将上述代码改为读取外部配置的静态工厂，仍然是对问题换了个地方。ProductServiece依赖ProductRepositoryFactory，ProductRepositoryFactory又依赖于SqlProductRepository和AzureProductRepository,因此依赖传递导致ProductServiece对后两者的依赖。

public static IProductRepository Create() 
{ 
    IConfigurationRoot configuration = new ConfigurationBuilder() 
        .SetBasePath(Directory.GetCurrentDirectory()) 
        .AddJsonFile("appsettings.json") 
        .Build(); 
    string repositoryType = configuration["productRepository"]; 
    switch (repositoryType) 
    { 
        case "sql": return new SqlProductRepository(); 
        case "azure": return AzureProductRepository(); 
        default: throw new InvalidOperationException("..."); 
    } 
} 

IProductRepository

1-3. 构造重载时的控制狂

下面案例中无参构造将SqlProductRepository作为外部预设，造成业务层对SQL数据层的依赖耦合

private readonly IProductRepository repository; 
public ProductService()                                 
    : this(new SqlProductRepository())                  
{                                                       
}                                                       
public ProductService(IProductRepository repository)    
{                                                       
    if (repository == null)                             
        throw new ArgumentNullException("repository");  
                                                        
    this.repository = repository;                       
} 

2. 服务定位

服务定位是指在组合根之外的位置，一步特定的一群不稳定依赖对象，作为依赖需求组件提供给应用程序。

在程序设计中，组合根”是指应用程序的起始点，负责组合（compose）整个应用程序的各个部分（如依赖注入容器、对象实例化、配置设置等）。Composition root通常位于应用程序的最顶层，是整个应用程序的组装中心。
具体来说，“组合根”负责以下几个主要任务：

实例化和配置应用程序中的各种对象和组件。

注册依赖关系，进行依赖注入（Dependency Injection）。

加载配置设置，设置应用程序的参数和行为。

协调应用程序中各个部分之间的交互和依赖关系。
通过将这些逻辑集中在一个地方，即“composition root”，可以实现应用程序的解耦和灵活性，使得应用程序的各个部分可以更容易地被替换、修改或扩展。这种设计模式有助于提高代码的可维护性和可测试性。

2-1. 示例：

... 
public class ProductService : IProductService 
{ 
    private readonly IProductRepository repository; 
	//无参构造函数，让人看不清楚依赖关系 
    public ProductService() 
    { 
	    //通过服务定位组件Locator来获取实例 
        this.repository = Locator.GetService<IProductRepository>(); 
    } 
    public IEnumerable<DiscountedProduct> GetFeaturedProducts() { ... } 
} 
... 
//简单服务定位的实现 
public static class Locator 
{ 
    private static Dictionary<Type, object> services =  
        new Dictionary<Type, object>(); 
	//注册实例 
    public static void Register<T>(T service) 
    { 
        services[typeof(T)] = service; 
    } 
	//获取实例 
	public static T GetService<T>()                     
    {                                                   
        return (T)services[typeof(T)];                  
    } 
    public static void Reset() 
    { 
        services.Clear(); 
    } 
} 
... 
//以服务定位来进行单元测试 
[Fact] 
public void GetFeaturedProductsWillReturnInstance() 
{ 
    // Arrange 
    var stub = ProductRepositoryStub();          
    Locator.Reset();                             
    Locator.Register<IProductRepository>(stub);  
    var sut = new ProductService(); 
	// Act 
    var result = sut.GetFeaturedProducts();      
    // Assert 
    Assert.NotNull(result); 
} 

2-2. 对服务定位反模式的反思

2-2-1. 服务定位的优点：

可以通过更改注册来支持延迟绑定。
可以并行开发代码，因为您是对接口进行编程，可以随意替换模块。
可以很好地分离关注点，因此没有什么能阻止您编写可维护的代码，但这样做会变得更加困难。
可以用TestDoubles来替换依赖项，从而确保了可测试性。

在程序开发中，Test Doubles是一种用于测试的替代品或模拟对象。它们被用来替代真实的依赖项或组件，以便在测试过程中隔离被测代码的行为。Test Doubles有多种类型，包括：

Dummy Objects（哑对象）：它们只是占位符，没有实际的实现，仅用于满足方法签名或参数要求。

Fake Objects（伪对象）：它们是真实的实现，但是在测试环境中使用简化的版本。例如，使用内存数据库替代真实的数据库。

Stub Objects（存根对象）：它们提供了预定义的响应，以便在测试中模拟特定的行为。例如，返回固定的数据或执行预定的操作。

Spy Objects（间谍对象）：它们类似于存根对象，但还会记录被调用的方法和参数，以便在测试中进行断言和验证。

Mock Objects（模拟对象）：它们是预先配置的对象，具有预期的行为和交互。通过使用断言来验证它们与被测代码之间的交互是否符合预期。
使用Test Doubles可以帮助在测试过程中隔离和控制依赖项，使测试更加可靠、可重复和可维护。这些替代品可以根据测试需要进行创建和配置，以模拟各种场景和条件。

2-2-2. 服务定位的坏处：

和服务定位器绑定的一些类别可能成为冗余
这个类使它的依赖性变得不明显

注意
在组合根区域使用DI容器，并不算服务定位反模式，它是一个基础框架组件。

3. 环境上下文

ambient context即环境上下文。在软件开发中，ambient context 是指一种模式，用于在应用程序中共享环境相关的信息或配置，而无需显式传递这些信息给每个组件或方法。这种模式通常通过线程本地存储（Thread Local Storage）或者类似的机制实现。一般在组合根之外的地方，透过一个全局存取的static修饰子类别成员。
通过 ambient context 模式，可以在整个应用程序中访问共享的环境信息，比如当前用户身份、语言设置、主题样式等，而无需在每个方法或组件中显式地传递这些信息。这种模式的优点在于可以简化代码，提高可维护性，并且避免了在每个组件中传递相同的上下文信息的重复工作。
需要注意的是，虽然 ambient context 可以简化代码，但过度使用它可能会导致代码难以理解和调试，因为它引入了隐式的依赖关系。因此，在使用 ambient context 模式时需要权衡利弊，并遵循良好的设计原则。

3-1. 示例

public string GetWelcomeMessage() 
{ 
    ITimeProvider provider = TimeProvider.Current;      
    DateTime now = provider.Now; 
    string partOfDay = now.Hour < 6 ? "night" : "day"; 
    return string.Format("Good {0}.", partOfDay); 
} 

3-2. 示例-查询时间用的环境上下文

//查询当前系统时间的管道 
public interface ITimeProvider 
{ 
    DateTime Now { get; }       
} 
... 
静态类提供全局范围可读取实例 
public static class TimeProvider                        
{ 
    //内建预设初始化 
    private static ITimeProvider current = 
        new DefaultTimeProvider(); 
	//全局范围类可对ITimeProvider不稳定依赖进行读取，设置的静态属性成员	 
    public static ITimeProvider Current                 
    { 
        get { return current; } 
        set { current = value; } 
    } 
	//预设 
    private class DefaultTimeProvider : ITimeProvider   
    { 
        public DateTime Now { get { return DateTime.Now; } } 
    } 
} 

以环境物件反模式进行单元测试

[Fact] 
public void SaysGoodDayDuringDayTime() 
{ 
    // Arrange 
    DateTime dayTime = DateTime.Parse("2019­01­01 6:00"); 
    var stub = new TimeProviderStub { Now = dayTime }; 
	//将原本预设替换为测试用替身 
    TimeProvider.Current = stub; 
	//WelcomeMessageGenerator构造API未揭露其需要ITimeProvier这层关系 
    var sut = new WelcomeMessageGenerator();            
    // Act 
    string actualMessage = sut.GetWelcomeMessage();    //TimeProvider.Current与GetWelcomeMessage时序耦合 
    // Assert 
    Assert.Equal(expected: "Good day.", actual: actualMessage); 
} 

3-3. 对环境上下文反模式反思

3-3-1. 环境上下文弊端

“依赖项”已被隐藏起来了。
测试变得更加困难。
很难根据其上下文来改变依赖关系。
在依赖的初始化和使用之间存在时间耦合。

3-3-2. 将环境上下文重回DI正途

将这些环境上下文的调用集中到一处，这个订房的绝佳选择就是调用构造器的时候。
建立一个private readonly私有只读成员，用于存放透过环境上下文索取的依赖对象，之后类别中的所有需要这份以来的程序，都直接引用这个新的私有成员。
改进后的程序：

public class WelcomeMessageGenerator 
{ 
    private readonly ITimeProvider timeProvider; 
    public WelcomeMessageGenerator(ITimeProvider timeProvider) 
    { 
        if (timeProvider == null) 
            throw new ArgumentNullException("timeProvider"); 
        this.timeProvider = timeProvider; 
    } 
    public string GetWelcomeMessage() 
    { 
        DateTime now = this.timeProvider.Now; 
        ... 
    } 
} 

4. 限制性构造

限制性构造指某个抽象接口在实例化时，强制需要这些实体类别中有个同样识别定义的构造器，一遍延迟绑定。

4-1. 示例

强制对构造函数执行精确的签名

public class SqlProductRepository : IProductRepository 
{ 
    public SqlProductRepository(string connectionStr)   
    { 
    } 
} 
public class AzureProductRepository : IProductRepository 
{ 
    public AzureProductRepository(string connectionStr) 
    { 
    } 
} 

4-2. 示例-ProductRepository的延迟绑定

string connectionString = this.Configuration            
    .GetConnectionString("CommerceConnectionString");   
var settings =                                          
    this.Configuration.GetSection("AppSettings");       
                                                        
string productRepositoryTypeName =                      
    settings.GetValue<string>("ProductRepositoryType"); 
var productRepositoryType =                             
    Type.GetType(                                       
        typeName: productRepositoryTypeName,            
        throwOnError: true);                            
var constructorArguments = 
    new object[] { connectionString }; 
IProductRepository repository =                         
    (IProductRepository)Activator.CreateInstance(       
        productRepositoryType, constructorArguments); 
		 
... 
{ 
  "ConnectionStrings": { 
    "CommerceConnectionString": 
      "Server=.;Database=MaryCommerce;Trusted_Connection=True;" 
  }, 
  "AppSettings": { 
    "ProductRepositoryType": "SqlProductRepository, Commerce.SqlDataAccess" 
  }, 
} 

实际上，这没有意义，因为这表示了对依赖项的构造函数的意外约束。在这种情况下，您有一个隐式的要求，即IProductRepository的任何实现都应该有一个以单个字符串作为输入的构造函数,这就使IProductRepository实例化时受到额外的限制。

4-3. 限制性构造反模式的反思

虽然类似上面代码中这种限制最普遍，但在灵活性方面的成本是巨大的。无论您如何约束对象构造，您都会失去灵活性。
当您有多个类需要相同的依赖关系时，您可能希望在所有这些类之间共享一个实例。只有当您可以从外部注入该实例时，这才有可能实现。尽管您可以在每个类中编写代码，以从配置文件中读取类型信息并使用Activator.CreateInstance。 CreateInstance来创建正确的实例类型，它确实需要以这种方式共享单个实例。相反，同一类的多个实例会占用更多的内存。

4-4. 将限制器重回正途

借助抽象工厂模式，来产生抽象接口的实例，然后通过抽象接口的类别来配合某个构造器识别定义。

ABFac

public class SqlProductRepository : IProductRepository 
{ 
    private readonly IUserContext userContext; 
    private readonly CommerceContext dbContext; 
    public SqlProductRepository( 
        IUserContext userContext, CommerceContext dbContext) 
    { 
        if (userContext == null) 
            throw new ArgumentNullException("userContext"); 
        if (dbContext == null) 
            throw new ArgumentNullException("dbContext"); 
        this.userContext = userContext; 
        this.dbContext = dbContext; 
    } 
} 

SqlProductRepository 实现了IproductRespository接口，并且没有对IUserContext对象产生依赖。
负面案例

public class SqlProductRepositoryFactory 
    : IProductRepositoryFactory 
{ 
    private readonly string connectionString; 
	 
	//传入Mircorsoft的IConfigurationRoot让后读取需要的设定值。玩意要是设定值不存在，会在构建时抛出异常 
    public SqlProductRepositoryFactory( 
        IConfigurationRoot configuration)               
    { 
        this.connectionString = 
            configuration.GetConnectionString(          
                "CommerceConnectionString"); 
    } 
    public IProductRepository Create() 
    { 
	    //使用位于不同程序集中的依赖项创建一个新的IProductRepositoryFactory 
        return new SqlProductRepository(                
            new AspNetUserContextAdapter(), 
            new CommerceContext(this.connectionString)); 
    } 
} 

posted @ 2024-05-25 23:06 世纪末の魔术师阅读(2) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

世纪末的魔术师

Unity最受欢迎插件推荐👈
为慈善助力-极大优惠获取unity插件

反模式 DI anti-patterns

反模式 DI anti-patterns

一、一、反模式 DI anti-patterns

1. 控制狂 Control freak

1-1. 示例：

1-2. 工厂模式下的反模式

1-3. 构造重载时的控制狂

2. 服务定位

2-1. 示例：

2-2. 对服务定位反模式的反思

2-2-1. 服务定位的优点：

2-2-2. 服务定位的坏处：

3. 环境上下文

3-1. 示例

3-2. 示例-查询时间用的环境上下文

3-3. 对环境上下文反模式反思

3-3-1. 环境上下文弊端

3-3-2. 将环境上下文重回DI正途

4. 限制性构造

4-1. 示例

4-2. 示例-ProductRepository的延迟绑定

4-3. 限制性构造反模式的反思

4-4. 将限制器重回正途

公告

世纪末的魔术师

Unity最受欢迎插件推荐👈为慈善助力-极大优惠获取unity插件

反模式 DI anti-patterns

反模式 DI anti-patterns

一、一、反模式 DI anti-patterns

1. 控制狂 Control freak

1-1. 示例：

1-2. 工厂模式下的反模式

1-3. 构造重载时的控制狂

2. 服务定位

2-1. 示例：

2-2. 对服务定位反模式的反思

2-2-1. 服务定位的优点：

2-2-2. 服务定位的坏处：

3. 环境上下文

3-1. 示例

3-2. 示例-查询时间用的环境上下文

3-3. 对环境上下文反模式反思

3-3-1. 环境上下文弊端

3-3-2. 将环境上下文重回DI正途

4. 限制性构造

4-1. 示例

4-2. 示例-ProductRepository的延迟绑定

4-3. 限制性构造反模式的反思

4-4. 将限制器重回正途

公告

Unity最受欢迎插件推荐👈
为慈善助力-极大优惠获取unity插件