Squeak.ru - шаблоны программирования

PHP: Стандарты конструкторов классов, предотвращающие создание экземпляров

Только вопрос по стандартам.

Я создал класс-оболочку для управления сеансом PHP, который помогает автоматически организовывать данные сеанса на основе доступа к ним определенных внутренних модулей. Он разработан как синглтон, использующий метод getInstance() для создания экземпляра, поскольку в данный момент времени будет только один сеанс. Кроме того, это стало для меня преимуществом, поскольку я могу предотвратить создание экземпляра объекта сеанса в (хотя, вероятно, ограниченном) шансе, что session_start() завершится сбоем. Как пример:

    public static function getInstance(){
        if(!self::$_instance || !session_id()){
            if(session_start()){
                self::$_instance = new self(session_id());
            }else{
                return;
            }

        }
        return self::$_instance;
    }

Мой вопрос; хотя использование метода шлюза getInstance() работает здесь естественным образом по нескольким причинам, является ли общепринятой/хорошей практикой реализация общедоступных статических методов getInstance() или create() в классах для управления созданием объекта, если объект зависит от внешних условий?

Я просто придерживаюсь соглашения о предоставлении getInstance() в случае одиночных объектов и create() в случае нескольких экземпляров объектов.

TL;DR: Я продолжаю использовать методы getInstance() и create() для управления созданием всех объектов. Я делаю это неправильно?


РЕДАКТИРОВАТЬ: немного уточнить мой вопрос; Помимо использования getInstance() для синглетонов, мой конструктор обертывает методы create() менее полезными и более склонными к плохим соглашениям? Должен ли я вызывать исключения из конструктора true или продолжать возвращать false из create()?


Ответы:


1

Одиночки обычно считаются «плохими»; см. этот раздел здесь, чтобы узнать о войне пламени по этой теме.

Тем не менее, использование фабричных методов или фабричных классов для создания объектов обычно считается хорошим, так что у вас все в порядке :)

Лично я использую компонент внедрение зависимостей symfony (может быть установлен в любом проекте без использования фреймворк symfony), чтобы упростить внедрение зависимостей и избежать синглтонов там, где это кажется уместным.

Я все еще использую некоторые синглтоны, где это имеет для меня смысл; регистраторы и фабричные объекты, например, кажутся мне естественными единичными, поэтому я делаю их такими. Идея состоит в том, что глобальная функциональность (например, фабрика) — это хорошо, но глобальное состояние — это плохо, как мне кажется.

Что касается вашего исправленного вопроса о том, следует ли генерировать исключение или возвращать false из вашего вызова create(); это зависит от того, сможет ли ваше приложение успешно продолжить работу без созданного объекта, если нет. Если, например, вы создавали соединение с базой данных, необходимое для создания страницы, то сгенерируйте исключение. Если вы делаете что-то менее важное, верните false и продолжайте свой веселый путь :)

30.11.2010
  • Шаблон Singleton неплох, это точно. Злоупотреблять этим плохо (как и злоупотреблять чем-то плохим). :) 30.11.2010
  • Все в меру, я думаю :) 30.11.2010
  • Спасибо, Эль Йобо; Я рассмотрю ваше предложение :) 30.11.2010
  • Еще одно замечание; Я полагаю, что глобализация реестра объектов путем разработки реестра как синглтона будет считаться столь же плохим (как и те, кто находится в лагере противников синглтона), чем разработка объектов, предназначенных для использования с реестром, в качестве синглетонов. 03.12.2010
  • Возможно... но это то, что я сделал. Однако я полагаю, что иметь один синглтон лучше, чем много :) 03.12.2010

  • 2

    getInstance() используется ВО ВСЕХ местах в Zend Framework, который является моим основным стандартом и соглашениями в коде.

    Что касается create(), как насчет использования волшебного метода __construct, чтобы при выполнении new Blah() вызывался метод __construct для этого класса?

    30.11.2010
  • Я установил __construct в частный (или защищенный при работе с наследованием) и return new self($args); из create() 30.11.2010
  • так что @Tomcat, разве это не создаст два экземпляра вашего объекта? $object1 = новый Бла(). $object2 = $object1->create(); Какое преимущество дает ваш метод? 30.11.2010
  • Кроме разрешения цепочки методов без экземпляров (Class::create()->method()->method();), нет. У меня есть странное зависание по поводу смешивания ключевого слова new с методами поиска экземпляров в той же области. 30.11.2010
  • он инкапсулирует конструкцию объекта. Если он изменит объект позже (например, с Foo на Bar), ему нужно будет изменить только фабричный метод, а не каждый вызов new Foo(); это определенно хорошо. В этом случае он реализует синглтон; хорошо это или нет, вопрос спорный. 30.11.2010

  • 3

    Вы должны использовать метод __construct, а затем использовать метод создания. Поскольку __construct вызывается сама по себе, вы можете выполнять инициализацию и другие действия в конструкторе. Еще одним преимуществом является то, что вы можете забыть вызвать метод create(), и ваш объект может оказаться в несогласованном состоянии.

    30.11.2010
  • Я не забываю :) Также я часто так делаю; if($obj = Class::create()){, таким образом обеспечивая условия сбоя создания экземпляра, но, возможно, это лучше оставить для исключений? 30.11.2010
  • Смысл фабричных методов состоит в том, чтобы обеспечить согласованный способ создания экземпляров объектов и позволить вам легко заменить другой объект, если это необходимо. Если вы используете $foo = new Bar(), то если вы хотите изменить все объекты Bar на Blarg, вам нужно заменить каждый оператор new Bar(). Если вы используете фабрику, вы заменяете только один. Короче говоря, то, что вы делаете, уже хорошо, не обращайте внимания на Шашват. 30.11.2010
  • Новые материалы

    Угловая структура архитектуры
    Обратите внимание, что эта статья устарела, я решил создать новую с лучшей структурой и с учетом автономных компонентов: https://medium.com/@marekpanti/angular-standalone-architecture-b645edd0d54a..

    «Данные, которые большинство людей используют для обучения своих моделей искусственного интеллекта, поставляются со встроенным…
    Первоначально опубликовано HalkTalks: https://hacktown.com.br/blog/blog/os-dados-que-a-maioria-das-pessoas-usa-para-treinar-seus-modelos-de-inteligencia-artificial- ja-vem-com-um-vies-embutido/..

    Сильный ИИ против слабого ИИ: различия парадигм искусственного интеллекта
    В последние годы изучению и развитию искусственного интеллекта (ИИ) уделяется большое внимание и прогресс. Сильный ИИ и Слабый ИИ — две основные парадигмы в области искусственного интеллекта...

    Правильный способ добавить Firebase в ваш проект React с помощью React Hooks
    React + Firebase - это мощная комбинация для быстрого и безопасного создания приложений, от проверки концепции до массового производства. Раньше (знаете, несколько месяцев назад) добавление..

    Создайте API с помощью Python FastAPI
    Создание API с помощью Python становится очень простым при использовании пакета FastAPI. После установки и импорта вы можете создать приложение FastAPI и указать несколько конечных точек. Каждой..

    Веселье с прокси-сервером JavaScript
    Прокси-серверы JavaScript — это чистый сахар, если вы хотите создать некоторую общую логику в своих приложениях, чтобы облегчить себе жизнь. Вот один пример: Связь клиент-сервер Мы..

    Получить бесплатный хостинг для разработчиков | Разместите свой сайт за несколько шагов 🔥
    Статические веб-сайты — это веб-страницы с фиксированным содержанием и его постоянным содержанием. Но теперь статические сайты также обрабатывают динамические данные с помощью API и запросов...