java - 这是什么设计模式？适配器？

Question

[请参阅下面的更新]

我很难定义模式。我的同事说这是适配器模式。我不知道。我们陷入困境主要是因为我们想要正确命名我们的组件。

问题:是适配器模式吗？如果不是的话是什么？如果是其他事情，这是实现这个想法的最佳方式吗？

总而言之，它是一个与子组件(这些提供者吗？)共享接口(interface)的主组件(这是适配器吗？)。 主要组件决定/编排调用哪些子组件。主要组件充当某种“包装器”来调用具有相同接口(interface)的其他组件之一。其实例通过构造函数注入(inject)。

假设:

1. 为简单起见，我们暂时忽略DR/IoC，但我们理解并应用该模式/原则。
2. 该代码不是最佳实现形式...请随意提出建议。
3. 我对“主/子”一词的使用并不意味着某种继承......只是我的命名不当，如果令人困惑的话。
4. 它与语言无关，因为我喜欢 C# 和 Java 人员的贡献以及他们分享的知识。

我正在使用社交网络场景，其中主要组件获取标签上的统计信息并实例化适当的社交子组件(有一个社交组件接口(interface):

ISocialComponent
{
    SomeStatsObject GetStats(string hashTag);
}

社交子组件实现 ISocialComponent 接口(interface)

Twitter 子组件

public class TwitterSubComponent : ISocialComponent
{
    public SomeStatsObject GetStats(string hashTag)
    {
        return SomeMethodThatReturnsStatsObject(hashTag);   
    }

    private SomeMethodThatReturnsStatsObject(string hashTag)
    {
        //... Twitter-specific code goes here
    }
}

Facebook 子组件

public class FacebookSubComponent : ISocialComponent
{
    public SomeStatsObject GetStats(string hashTag)
    {
        return SomeMethodThatReturnsStatsObject(hashTag);
    }

    private SomeMethodThatReturnsStatsObject(string hashTag)
    {
        //... Facebook-specific code goes here
    }
}

Instagram 子组件

public class InstagramSubComponent : ISocialComponent
{
    public SomeStatsObject GetStats(string hashTag)
    {
        return SomeMethodThatReturnsStatsObject(hasTag);
    }

    private SomeMethodThatReturnsStatsObject(string hashTag)
    {
        //... Instagram-specific code goes here
    }
}

主要组件

有一个主要的社交组件对象，它调用实现共享 ISocialComponent 接口(interface)的任何一个子组件(定义如下)

public class MainSocialComponent : ISocialComponent
{
    //this is an enum
    private RequestedNetwork _requestedNetwork{ get; set;}

    //the SocialComponent instance is injected outside of this class
    private readonly ISocialComponent _socialComponent;

    public MainSocialComponent(ISocialComponent socialComponent)
    {
       _socialComponent = socialComponent;
    } 

    public SomeStatsObject GetStats(string hashTag) 
    {
        return _socialComponent.GetStats(hashTag)

        /**** original code, kept for historical purposes****
        switch(_requestedNetwork)
        {
            case RequestedNetwork.Twitter:
                var twit = new TwitterSubComponent();
                return twit.GetStats(hashTag)
                break;

            case RequestedNetwork.Facebook:
                var fb = new FacebookSubComponent();
                return fb.GetStats(hashTag)
                break;

            case RequestedNetwork.Instagram:
                var in = new InstagramSubComponent();
                return in.GetStats(hashTag)
                break;

            default:
                throw new Exception("Undefined Social Network");
                break;
        }*/
    }
}

更新:

我明白为什么有人说它是工厂模式，因为它正在创建对象。我曾提到过我们使用 IoC 容器和 DR。我错误地排除了这一点。我重构了代码

Answer 1

正如其他人所提到的，这是工厂/服务模式的一部分，该模式在依赖注入(inject)和控制反转中非常流行。

现在虽然没有理由将您的子组件声明为非静态，因为您没有将实例保存到任何内容。

所以在我看来，除非您缺少将组件添加到列表或其他内容的代码，否则您可以这样做:

public static class InstagramSubComponent : ISocialComponent
{
    public static SomeStatsObject GetStats(string hashTag)
    {
        return stuff;
    }
}

public class MainSocialComponent : ISocialComponent
{
    //this is an enum
    private RequestedNetwork _requestedNetwork{ get; set;}

    private static var Mappings = new Dictionary<string, Func<SomeStatsObject>> {
        { "Twitter", TwitterSubComponent.GetStats },
        { "Facebook", FacebookSubComponent.GetStats },
        { "Instagram", InstagramSubComponent.GetStats }
    } 

    public SomeStatsObject GetStats(string hashTag) 
    {
       return Mappings[hashTag].invoke(); 
    }
}

}

现在，如果您正在做一些事情，例如将子组件的实例实际保存到列表中以供稍后使用或其他操作，那么这会改变一切。但我没有看到这一点，所以如果这些方法很简单，就没有理由不将其全部静态化。

如果它们非常复杂，那么您将需要使用依赖项注入(inject)，以便可以正确地对所有内容进行单元测试。