学习单一责任原则与C#

我试图学习单一责任原则(SRP)，但它是相当困难，因为我有一个巨大的困难，以确定什么时候，我应该从一个类，我应该把/组织它应该删除。

我在搜索一些材料和代码示例，但大多数材料我发现，而不是让它更容易理解，使其难以理解。

For example if I have a list of Users and from that List I have a
class Called Control that does lots of things like Send a greeting and
goodbye message when a user comes in/out,verify weather the user
should be able to enter or not and kick him,receive user commands and messages,etc.

从这个例子你不需要太多的了解我已经做了太多的一个类，但我不够清楚如何拆分和重组后。

如果我理解SRP，我会有一个类加入频道，问候和再见，用户验证类，阅读命令的类，对不对？

但是我在哪里和如何使用踢脚？

我有验证类，所以我相信我会有所有类型的用户验证，包括天气或不是一个用户应该被踢。

因此，kick函数将在通道连接类内部，如果验证失败，将被调用？

例如：

public void UserJoin(User user)
{
    if (verify.CanJoin(user))
    {
        messages.Greeting(user);
    }
    else
    {
        this.kick(user);
    }
}

如果你们可以在这里借给我一个容易理解的在线和免费的C#材料，或者通过显示我如何分割引用的示例，如果可能的话一些示例代码，建议等等。

让我们从 Single Responsibility Principle(SRP)实际意思是什么开始：

类应该只有一个理由改变。

这有效地意味着每个对象(类)应当具有单个责任，如果一个类具有多个责任，这些责任变得耦合并且不能被独立地执行，即一个变化可以影响甚至在特定实现中破坏另一个。

一个肯定必须读这是源本身(从“Agile Software Development,Principles,Patterns,and Practices”的pdf章)：The Single Responsibility Principle

话说，你应该设计你的类，所以他们最好只做一件事，做一件好事。

首先想想你有什么“实体”，在你的例子中，我可以看到用户和频道以及它们之间通信的媒介(“消息”)。这些实体彼此之间具有一定的关系：

>用户具有他已经加入的多个频道
>一个频道有多个用户

这也自然地导致以下功能列表：

>用户可以请求加入频道。
>用户可以向已加入的频道发送消息
>用户可以离开频道
>频道可以拒绝或允许用户的请求加入
>频道可以踢用户
>频道可以向该频道中的所有用户广播消息
>频道可以向个别用户发送问候消息
渠道

SRP是一个重要的概念，但不应该独立 – 对于您的设计同样重要的是Dependency Inversion Principle(DIP)。要将其纳入设计中，请记住，用户，消息和通道实体的特定实现应取决于抽象或接口，而不是特定的具体实现。为此，我们从设计接口而不是具体类开始：

public interface ICredentials {}

public interface IMessage
{
    //properties
    string Text {get;set;}
    DateTime TimeStamp { get; set; }
    IChannel Channel { get; set; }
}

public interface IChannel
{
    //properties
    ReadOnlyCollection<IUser> Users {get;}
    ReadOnlyCollection<IMessage> MessageHistory { get; }

    //abilities
    bool Add(IUser user);
    void Remove(IUser user);
    void broadcastMessage(IMessage message);
    void UnicastMessage(IMessage message);
}

public interface IUser
{
    string Name {get;}
    ICredentials Credentials { get; }
    bool Add(IChannel channel);
    void Remove(IChannel channel);
    void ReceiveMessage(IMessage message);
    void SendMessage(IMessage message);
}

这个列表没有告诉我们是什么原因这些功能被执行。我们最好把“为什么”(用户管理和控制)的责任放在一个单独的实体中 – 这样，如果“为什么”改变，用户和频道实体不必改变。我们可以利用战略模式和DI这里，并可以有任何具体的实现IChannel取决于一个IUserControl实体，给我们“为什么”。

public interface IUserControl
{
    bool ShouldUserBeKicked(IUser user,IChannel channel);
    bool MayUserJoin(IUser user,IChannel channel);
}

public class Channel : IChannel
{
    private IUserControl _userControl;
    public Channel(IUserControl userControl) 
    {
        _userControl = userControl;
    }

    public bool Add(IUser user)
    {
        if (!_userControl.MayUserJoin(user,this))
            return false;
        //..
    }
    //..
}

你看到在上面的设计SRP甚至不是接近完美，即IChannel仍然依赖于抽象IUser和IMessage。

最后，应该努力实现灵活，松耦合的设计，但总是要做出折衷，灰色区域也取决于您希望应用程序改变的位置。

SRP在我看来极端，导致非常灵活，但也碎片和复杂的代码，可能不是那么容易理解作为简单但有点更紧密耦合的代码。

事实上，如果两个责任总是在同一时间改变，你可以说，不应该把它们分成不同的类，因为这将导致马丁，“无需复杂的气味”。对于从不改变的责任也是如此 – 行为是不变的，并且没有必要分裂它。

这里的主要思想是，你应该做出一个判断呼叫，你看到责任/行为可能在未来独立地改变，这种行为是相互依赖的，并且总是在同一时间改变(“拴在一起”)并且哪种行为首先不会改变。

学习单一责任原则与C#

相关推荐