Каково будет правильное соглашение об именах, когда вы прячете зависимости за фасадом? - PullRequest
0 голосов
/ 26 сентября 2018

У меня есть класс, выполняющий какую-то операцию, скажем, разбор, и это будет публичный репозиторий.Поскольку конструктор имеет некоторую сложность и не важен для конечного пользователя, я хотел спрятать его за фасадом.

// interface
interface ParserInterface {
    function parse(string $input): Document;
}

// implementation
class ParserImplementation implements ParserInterface {
    function __construct(
        Normalizer $normalizer,
        Tokenizer $tokenizer,
        Interpreter $interpreter,
        etc.
    ) {
        $this->normalizer = $normalizer;
        $this->tokenizer = $tokenizer;
        $this->interpreter = $interpreter;
    }

    function parse(string $input): Document {
        $normalizedInput = $this->normalizer->normalize($input);
        $tokens = $this->tokenizer->tokenize($normalizedInput);
        return $this->interpreter->interpret($tokens);
    }
}

// facade
class ParserFacade implements ParserInterface {
    private $parser;

    function __construct() {
        $this->parser = new ParserImplementation(
            new Normalizer(),
            new Tokenizer(),
            etc.
        );
    }

    function parse(string $input) {
        return $this->parser->parse($input);
    }
}

Как видите, там также есть интерфейс.

Теперь для внешнего приложения это фасад, который является синтаксическим анализатором.Для независимого кода это интерфейс, который является синтаксическим анализатором.И для меня, развивая вышеупомянутое решение, именно ParserImplementation является реальным синтаксическим анализатором, т.е. именно он охватывает всю логику синтаксического анализа.Так что теперь я совершенно заблудился относительно правильного соглашения об именах.

Я бы предпочел назвать интерфейс просто как Parser, а fasade как что-то, немного заявляя о моем намерении: CustomParser, потому что целое - это пользовательскийреализация чего-то, что имеет некоторую стандартную реализацию.Но тогда я не могу найти шаблон для именования внутреннего класса (ParserImplementation в приведенном выше коде).

Есть ли в этом отношении устоявшаяся практика?

1 Ответ

0 голосов
/ 27 сентября 2018

Это довольно субъективно, но то, что я обычно делаю, и то, что я вижу чаще всего, выглядит примерно так:

Интерфейс : ParserInterface

Аннотация: ParserAbstract

Реализация : Parser

Фасад : Именуется для определенной цели (CsvParser, XmlParser и т. Д.) Или что-то вроде DefaultParserили GenericParser

Если бы это был я, я бы, вероятно, справился бы с абстракцией, а не с фасадным подходом.Поэтому я бы изменил класс ParserImplementation на абстрактный, и чтобы ваш ParserFacade расширил этот класс, и просто назвал его Parser.Если вы хотите предоставить оптимизированную реализацию класса этого , то вы можете выбрать маршрут фасада, но в этом случае, вероятно, в этом не будет необходимости.

<?php

// interface
interface ParserInterface
{
    function parse(string $input): Document;
}

// abstract
abstract class ParserAbstract implements ParserInterface
{
    function __construct(
        Normalizer $normalizer,
        Tokenizer $tokenizer,
        Interpreter $interpreter
    )
    {
        $this->normalizer  = $normalizer;
        $this->tokenizer   = $tokenizer;
        $this->interpreter = $interpreter;
    }

    function parse(string $input): Document
    {
        $normalizedInput = $this->normalizer->normalize($input);
        $tokens          = $this->tokenizer->tokenize($normalizedInput);
        return $this->interpreter->interpret($tokens);
    }
}

// Concrete class
class Parser extends ParserAbstract
{
    function __construct()
    {
        parent::__construct(
            new Normalizer(),
            new Tokenizer(),
            new Interpreter()
        );
    }
}

// Concrete class
class XmlParser extends ParserAbstract
{
    function __construct()
    {
        parent::__construct(
            new NormalizerXml(),
            new TokenizerXml(),
            new Interpreter()
        );
    }
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...