Le modèle de supertype de couche: encapsulant l'implémentation commune dans les systèmes à plusieurs niveaux

Points de base

• Le mode supertype de couche est crucial dans les systèmes multicouches, et il peut encapsuler des implémentations communes dans différentes classes, facilitant ainsi la réutilisation du code et la réduction de la duplication.
• La mise en œuvre du modèle de supertype de couche implique la création d'une classe de base partagée qui résume la logique et les propriétés publiques, puis s'étend par une sous-classe plus spécifique.
• Ce mode aide à maintenir une architecture de code plus claire, car elle permet la modification des fonctionnalités partagées en un seul endroit, améliorant ainsi la maintenabilité et l'évolutivité.
• Le modèle d'hypertype de couche simplifie non seulement la base de code, mais s'aligne également bien avec le principe de responsabilité unique car il sépare le comportement public du comportement spécifique à la classe.
• Bien que ce modèle offre de nombreux avantages en réduisant le code de la passerelle et le code redondant, il doit être appliqué avec prudence pour éviter de créer des structures de superclasse trop complexes ou grandes qui peuvent être difficiles à gérer.

L'héritage

, comme l'une des pierres angulaires de la programmation orientée objet, est comme une épée à double tranchant. Système. Bien qu'il existe de nombreux pièges dans l'héritage, la plupart d'entre eux peuvent être atténués par une utilisation rationnelle et modérée. La réutilisation du code est la cause profonde de l'héritage. L'héritage fournit un moyen facile de générer facilement un grand nombre d'objets sémantiquement interdépendants sans duplication de code. Son concept est très simple mais puissant: mettez d'abord autant de logique que possible dans les limites du type de base (généralement des classes abstraites, mais aussi des classes concrètes), puis commencez à dériver des sous-types raffinés en fonction des besoins plus spécifiques. Ce processus est généralement effectué sur une base "par couche", fournissant ainsi à chaque couche son propre ensemble de supertypes, dont les fonctions de base sont affinées et étendues à leur tour par les sous-types correspondants. Sans surprise, cette encapsulation / boucle dérivée en double suit un modèle de conception appelé "couche supertype" (oui, il a un vrai nom académique, bien qu'un peu naïf), dans les quelques lignes suivantes, je vais creuser la façon dont il fonctionne en interne , et vous pourrez voir à quel point il est facile de connecter ses fonctionnalités au modèle de domaine.

Exigences de type de super type de niveau - Définition du modèle de domaine gonflé

On peut dire que les supertypes de couche sont l'évolution naturelle et sélective du type de base "commun", sauf que ce dernier existe dans le cadre d'une couche spécifique. Cela joue un rôle important dans la conception multicouche où l'utilisation de fonctions de super-type est souvent une exigence nécessaire, pas seulement une décision arbitraire. En général, le moyen le plus efficace de comprendre le praticité derrière ce modèle est à travers certains exemples pratiques. Supposons donc que nous devons construire un modèle de domaine simple à partir de zéro, responsable de la définition de certaines interactions de base entre certains articles de blog et leurs commentaires correspondants. En gros, le modèle peut être facilement décrit comme une couche d'anémie, ne contenant que quelques classes squelettes pour modéliser des articles et des commentaires. La première classe de domaine et son contrat peuvent ressembler à ceci:

<?php namespace Model;

interface PostInterface
{
    public function setId($id);
    public function getId();

    public function setTitle($title);
    public function getTitle();

    public function setContent($content);
    public function getContent();

    public function setComment(CommentInterface $comment);
    public function setComments(array $comments);
    public function getComments();
}

<?php namespace Model;

class Post implements PostInterface
{
    protected $id;
    protected $title;
    protected $content;
    protected $comments = array();

    public function __construct($title, $content, array $comments = array()) {
        $this->setTitle($title);
        $this->setContent($content);
        if (!empty($comments)) {
           $this->setComments($comments); 
        }
    }

    public function setId($id) {
        if ($this->id !== null) {
            throw new BadMethodCallException(
                "The ID for this post has been set already.");
        }
        if (!is_int($id) || $id             throw new InvalidArgumentException(
                "The post ID is invalid.");
        }
        $this->id = $id;
        return $this;
    }

    public function getId() {
        return $this->id;
    }

    public function setTitle($title) {
        if (!is_string($title) 
            || strlen($title)             || strlen($title) > 100) {
            throw new InvalidArgumentException(
                "The post title is invalid.");
        }
        $this->title = htmlspecialchars(trim($title),
            ENT_QUOTES);
        return $this;
    }

    public function getTitle() {
        return $this->title;
    }

    public function setContent($content) {
        if (!is_string($content) || strlen($content)             throw new InvalidArgumentException(
                "The post content is invalid.");
        }
        $this->content = htmlspecialchars(trim($content),
            ENT_QUOTES);
        return $this;
    }

    public function getContent() {
        return $this->content;
    }

    public function setComment(CommentInterface $comment) {
        $this->comments[] = $comment;
        return $this;
    }

    public function setComments(array $comments) {
        foreach ($comments as $comment) {
            $this->setComment($comment);
        }
        return $this;
    }

    public function getComments() {
        return $this->comments;
    }
}

Le pilote de la classe de poste est une logique simple, ce qui se résume à la définition des données et du comportement de certaines entrées de publication de base. Cela devrait être facile à comprendre. Rendons maintenant le modèle un peu plus gros en y ajoutant une classe qui génère des commentaires associés à une entrée de blog spécifique. Son contrat et sa mise en œuvre sont les suivants:

<?php namespace Model;

interface CommentInterface
{
    public function setId($id);
    public function getId();

    public function setContent($content);
    public function getContent();

    public function setAuthor($author);
    public function getAuthor();
}

<?php namespace Model;

class Comment implements CommentInterface
{
    protected $id;
    protected $content;
    protected $author;

    public function __construct($content, $author) {
        $this->setContent($content);
        $this->setAuthor($author);
    }

    public function setId($id) {
        if ($this->id !== null) {
            throw new BadMethodCallException(
                "The ID for this comment has been set already.");
        }
        if (!is_int($id) || $id             throw new InvalidArgumentException(
                "The comment ID is invalid.");
        }
        $this->id = $id;
        return $this;
    }

    public function getId() {
        return $this->id;
    }

    public function setContent($content) {
        if (!is_string($content) || strlen($content)             throw new InvalidArgumentException(
                "The content of the comment is invalid.");
        }
        $this->content = htmlspecialchars(trim($content),
            ENT_QUOTES);
        return $this;
    }

    public function getContent() {
        return $this->content;
    }

    public function setAuthor($author) {
        if (!is_string($author) || strlen($author)             throw new InvalidArgumentException(
                "The author is invalid.");
        }
        $this->author = $author;
        return $this;
    }

    public function getAuthor() {
        return $this->author;
    }
}

comme le post, la classe de commentaires est simple. Mais maintenant, avec ces deux classes, nous pouvons utiliser le modèle. Par exemple:

<?php use LibraryLoaderAutoloader,   
    ModelPost,
    ModelComment;

require_once __DIR__ . "/Library/Loader/Autoloader.php";
$autoloader = new Autoloader;
$autoloader->register();

$post = new Post(
    "A sample post.",
    "This is the content of the post."
);

$post->setComments(array(
    new Comment(
        "One banal comment for the previous post.",
        "A fictional commenter"),
    new Comment(
        "Yet another banal comment for the previous post.",
        "A fictional commenter")
));

echo $post->getTitle() . " " . $post->getContent() . "<br></br>";

foreach ($post->getComments() as $comment) {
    echo $comment->getContent() . " " . $comment->getAuthor() .
        "<br></br>";
}

C'est en effet aussi efficace que le charme! L'utilisation de ce modèle est un processus assez simple qui vous oblige à créer d'abord des objets post-post, puis à les remplir de commentaires pertinents. Oui, la vie est douce et belle. Ok, jusqu'à présent, mais ça peut certainement être mieux! Je n'essaie pas de détruire la magie d'un moment aussi merveilleux, mais je dois admettre que je ressens un léger frisson à chaque fois que je vois la mise en œuvre des cours de message et de commentaires. Bien que ce ne soit pas un problème grave en soi, certaines méthodes (telles que setid () et setContent ()) montrent des symptômes typiques de la duplication de code. En raison de certains problèmes logiques, la résolution de ce problème sans négligence n'est pas aussi intuitive qu'elle peut paraître à première vue. Premièrement, bien qu'ils aient des relations sémantiques entre elles, chaque classe modélise réellement différents types d'objets. Deuxièmement, ils implémentent différentes interfaces, ce qui signifie qu'il est difficile de résumer la logique sans se retrouver avec une hiérarchie maladroite où la condition "IS-A" ne se tient jamais vraie. Surtout dans ce cas, nous pouvons adopter une approche plus détendue et traiter la publication et les commentaires comme des sous-types du très général de supertype de résumé. Ce faisant, la mise en place d'une implémentation partagée dans les limites d'une classe abstraite serait très simple, ce qui rend la définition des sous-types plus rationalisée. Étant donné que l'ensemble du processus d'abstraction n'a lieu qu'à la couche de domaine, la résume hypothétique sera traitée comme ... oui, vous l'avez deviné, un supertype de couche. Simple mais bon, non?

(le code et l'explication restants sont omis ici en raison des limitations de l'espace. Notez que les exemples de code dans le texte d'origine sont longs, et la traduction et la généralisation de tous les codes rendront la réponse trop verbeux. L'idée principale est de Créez une classe AbstractEntity pour extraire du code en double dans les classes Post, réduisant ainsi la redondance du code et l'amélioration de la maintenabilité. Comment Résumé

Bien que l'héritage soit souvent considéré comme un mécanisme de surestimation et d'abus, j'espère que très peu de personnes seront en désaccord maintenant que l'héritage est un mécanisme puissant qui fonctionne lorsqu'il est utilisé soigneusement dans un système multicouche empêche la duplication du code. L'utilisation d'un modèle simple comme la couche supertype est un exemple des nombreux avantages fascinants que l'héritage fournit lors de la création de sous-types qui partagent un grand nombre d'implémentations de chaudière entre elles.

(La partie FAQ du texte original est également omise ici parce que son contenu est une répétition et une extension des idées de base de l'article. La traduire tout le contenu rendra la réponse trop longue. Les idées de base ont été pleinement reflété dans la traduction ci-dessus.)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!