L'apprentissage Principe de Responsabilité Unique avec C#

Commençons par ce qui ne Principe De Responsabilité Unique (SRP) signifie réellement:

Une classe ne doit avoir qu'une seule raison de changer.

Effectivement cela signifie que chaque objet (classe) doit avoir une seule responsabilité, si une classe a plus d'un responsable de ces responsabilités, le tempo ne peut pas être exécuté de façon autonome, c'est à dire des changements dans l'un peut influencer ou même de briser l'autre dans une mise en oeuvre particulière.

Un must read pour ce qui est de la source elle-même (pdf chapitre de "Le Développement Logiciel Agile, Principes, Modèles et Pratiques"): Le Principe De Responsabilité Unique

Avoir dit que, vous devez concevoir vos classes si elles idéalement une chose et faire une chose bien.

D'abord penser à ce que les “entités” vous avez, dans votre exemple, je peux voir User et Channel et le moyen par lequel ils communiquent (“messages"). Ces entités entretiennent des relations les uns avec les autres:

• Un utilisateur dispose d'un nombre de canaux qu'il a rejoint
• Un canal a un certain nombre d'utilisateurs

Cela conduit naturellement à la suite de la liste des fonctionnalités:

• Un utilisateur peut demander à rejoindre un canal.
• Un utilisateur peut envoyer un message à un canal, il a rejoint l'
• Un utilisateur peut quitter un canal
• Un canal permet d'autoriser ou de refuser la demande d'un utilisateur à se joindre à
• Un canal permet d'éjecter un utilisateur
• Un canal permet de diffuser un message à tous les utilisateurs du canal
• Un canal permet d'envoyer un message de salutation à des utilisateurs individuels dans le
  canal

SRP est un concept important, mais doit à peine se tenir par lui-même – tout aussi important pour votre conception est la Inversion De Dépendance Principe (DIP). De les intégrer dans la conception rappelez-vous que votre particulier dans les implémentations de la User, Message et Channel entités dépendent d'une abstraction ou de l'interface, plutôt que la mise en œuvre concrète. Pour cette raison, nous commençons avec la conception d'interfaces qui ne sont pas les classes de béton:

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

Ce que cette liste ne nous dit pas, est pour quelle raison ces fonctionnalités sont exécutées. Nous sommes mieux de mettre la responsabilité de “pourquoi” (gestion des utilisateurs et de contrôle) dans une entité distincte – de cette façon, le User et Channel entités n'ont pas de changer de si le “pourquoi” du changement. Nous pouvons utiliser le modèle de stratégie et DI ici et peut avoir n'importe quelle mise en œuvre concrète de IChannel dépendent d'un IUserControl entité qui nous donne le "pourquoi".

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

Vous voyez que, dans la conception ci-dessus SRP n'est même pas proche de la perfection, c'est à dire un IChannel est toujours dépendante du abstractions IUser et IMessage.

À la fin, on devrait s'efforcer de souplesse, faiblement couplées, la conception, mais il y a toujours des compromis à être réalisés, et les zones grises également selon l'endroit où vous attendre votre demande de changement.

PRS prises à la extrême à mon avis, conduit à de très souples, mais aussi fragmenté et complexe de code qui pourrait ne pas être aussi facile à comprendre que plus simple mais un peu plus étroitement couplé code.

En fait, si deux responsabilités sont toujours devrait changer dans le même temps, vous avez sans doute ne doit pas les séparer en différentes classes que cela entraînerait, pour citer Martin, à une "odeur de la Complexité Inutile". Il en est de même pour les responsabilités qui ne changent jamais, le comportement est invariant, et il n'est pas nécessaire de le découper.

L'idée principale ici est que vous devez faire un appel de jugement où vous voyez des responsabilités/comportement peut être modifié de façon autonome dans l'avenir, dont le comportement est co-dépendants les uns des autres et changera toujours à la même époque ("lié à la hanche") et dont le comportement ne changera jamais, en premier lieu.

Ma recommandation est de commencer par la base: ce choses avez-vous? Vous avez mentionné plusieurs choses comme Message, User, Channel, etc. Au-delà de la simple choses, vous avez également comportements qui appartiennent à votre choses. Quelques exemples de comportements:

• un message peut être envoyé
• un canal peut accepter un utilisateur (ou pourrait-on dire qu'un utilisateur peut rejoindre un canal)
• un canal permet d'éjecter un utilisateur
• et ainsi de suite...

Remarque que c'est juste une façon de le regarder. Vous pouvez résumé de l'une de ces comportements jusqu'à ce que l'abstraction ne veut rien dire et tout! Mais, une couche d'abstraction ne fait généralement pas mal.

À partir d'ici, il y a deux écoles de pensée dans la programmation orientée objet: encapsulation complète et unique responsabilité. Le premier, de vous conduire à encapsuler tous les comportements liés à l'intérieur de son propriétaire de l'objet (ce qui inflexible de la conception, tandis que le second ne vous le conseille (résultant en couplage lâche et souple).

Je voudrais aller sur, mais il est tard et j'ai besoin de dormir un peu... je suis ce qui en fait une communauté post, si quelqu'un peut finir ce que j'ai commencé et d'améliorer ce que j'ai eu jusqu'à présent...

Heureux d'apprendre!