Правильно ли использовать switch/case в паттерне Фабричный метод / Factory Method?

Question

[atis //]

Всем привет.
По сути сабж.

Приведу пример:

interface House
{
    public function build();
    public function demolition();
}

class BlueHouse implements House
{
// реализация
}

class RedHouse implements House
{
// реализация    
}

class Factory
{
    public function factoryMethod($color)
    {
        switch($color)
        {
            case 'Red':
                return new RedHouse();
                
            case 'Blue':
                return new BlueHouse();

            default :
                throw new Exception('Undefined house\'s color');
        }
    }
}

Можно использовать Switch/Case для создания обьектов?
Пока ничего против не нашел но и не нашел что это 100% обязательно. Может кто сумеет опровергнуть?
Просьба отвечать только тем кто знаком с данным паттерном!!

Answer 1

[Евгений Бухарев]

class BlueHouse extends House{}

class RedHouse extends House{}

abstract class House
{
    const RED= 1;
    const BLUE= 2;

    public static function getInstance($color)
    {
        switch($color)
        {
            case self::RED:
                return new RedHouse();
                break;
            case self::BLUE:
                return new BlueHouse();
                break;
            default :
                throw new Exception('Undefined house\'s color');
                break;
        }
    }

    abstract function build();
    abstract function demolition();
}

Comments

[Евгений Бухарев]

Можно, почему нет

[atis //]

evgenybuckharev: Ыыыыыэээээээ... Сижу и плачу...

[Евгений Бухарев]

atis //: Прокомментируйте, интересно послушать

[atis //]

evgenybuckharev: зачем!!?? Вы используете тут СИНГЛТОН?

[Евгений Бухарев]

atis //: Наличие статического метода getInstance, это вовсе не значит что это Синглтон

[atis //]

evgenybuckharev: в таком случае если вы нарисуете Uml диаграмму и в классе кто то увидит данный метод он подумает что это Singleton!!

[atis //]

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

[Евгений Бухарев]

atis //: Так это не проблема, так как оба метода абстрактные, будь это абстрактный класс или интерфейс в данном случае нет разницы, так как данные методы всё равно надо будет реализовывать в наследуемых классах

[Евгений Бухарев]

atis //: Но что будет если необходимо задать какой то общий метод для наследуемых классов? что будете делать Вы, используя интерфейсы?

[Евгений Бухарев]

atis //: Так как данный статический метод getInstance возвращает объекты совершенно другого класса, а не свой собственный, то с UML диаграммой никаких проблем не будет, но если Вам режет глаз наименование метода, Вас никто не обязует называть его именно так, можете присвоить произвольное название

[Евгений Бухарев]

Здесь Важно понимать суть шаблона проектирования, получая объект House::getInstance(House::BLUE) либо House::getInstance(House::RED), вы должны программировать на основе интерфейса, либо как в данном случае на основе абстрактных методов, делается это для того, что если у вас возникнет необходимость ввести 10 новых цветов домом, у вас не порушится приложение, так как опять же интерфейс или абстрактный класс обязует реализовать заданные методы

[Евгений Бухарев]

atis //: Только я Вам рассказал о Abstract Factory, это частный случай Factory Method

Answer 2

[Finsh]

reflectionclass как-то использовал для этих целей рефлексию