Question

[请参阅下面的更新]

我很难定义一个模式。我的同事说它是适配器模式。我不确定。我们之所以陷入困境主要是因为我们想要正确命名我们的组件。

问题：是适配器模式吗？如果不是这样的话？如果它是别的，这是实现这个想法的最佳方式吗？

总而言之，它是一个主要组件（这是适配器吗？），它与子组件共享接口（是这些提供商吗？）。 ~~主要组件决定/协调哪个子组件被称为~~。主要组件表现为某种＆＃34;包装器＆＃34;调用具有相同接口的其他一个。其实例通过构造函数注入。

假设：

为简单起见，我们暂时忽略 DR / IoC ，但我们理解并应用模式/原则。
代码不是最好的实现形式......随时建议。
我对main / sub这个词的使用并没有推断出某种继承性......如果我感到困惑的话，那就是我的命名错误。
它与语言无关，因为我喜欢C＃和Java家伙的贡献，以及他们分享的知识。

我正在使用社交网络方案，其中主要组件获取hastag上的统计信息并实例化相应的社交子组件（有一个社交组件界面：

ISocialComponent
{
    SomeStatsObject GetStats(string hashTag);
}

社交子组件实现ISocialComponent接口

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接口的任何一个子组件（定义如下）

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;
        }*/
    }
}

更新

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

Answer 1

正如其他人所提到的，这是工厂/服务模式的一部分，它非常适用于依赖注入和控制反转。

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

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

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(); 
    }
}

}

现在，如果你正在做一些事情，比如实际将子组件的实例保存到列表中以供日后使用，那么这会改变一切。但我没有看到这一点，所以如果这些方法很简单，就没有理由不把它全部静止。

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

Answer 2

我相信您可以将SubComponent的创建提取到Factory并将此Factory传递给MainSocialComponent。在GetStats方法内部，您将调用_factory.Create(hashTag);而不是在返回的对象上调用GetStats。这样你就有了工厂模式。

Answer 3

这绝对是不适配器模式。

在大多数情况下，适配器模式执行以下操作：

•作为两个不兼容接口之间的桥梁。

•允许具有不兼容接口的类一起工作

您的情况更像是工厂模式。您可以使用高级抽象，并在需要时返回接口/组件的类型。

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

3 个答案: