Обычно место для классов factory статично, а также методы factory.
Было ли в GOF в книге Design Patterns указано, что фабрики и их методы ДОЛЖНЫ быть статичными, чтобы соответствовать строгому определению шаблона?
Имеет ли фабрики +/методы статические только последствия шаблона? данные состояния обычно не поддерживаются классом factory, поэтому они обычно статичны.
Я не верю, что существует такое понятие, как "строгое определение" шаблона. По своей природе существуют шаблоны, чтобы понять суть проблемы, которая снова и снова появляется в программном обеспечении и описывает, как может выглядеть решение.
В частности, с шаблоном Factory нет, нет требования, чтобы методы Factory были статическими. Суть шаблона в том, что у вас есть один объект, который отвечает за создание экземпляров другого класса. Как вы это делаете, это зависит от вас, хотя общий способ, как описано в шаблоне, заключается в использовании статического метода для класса. Однако в одной из наших систем есть механизм Factory, который фактически является двухступенчатым. Вы используете статический метод для класса для создания объекта Factory, который может быть настроен для выбора между набором реализаций, а затем использовать объект Factory для исключения экземпляров объекта, который вам нужен для реального работа.
Также рассмотрим реализацию шаблона Factory на языке, который не имеет статических методов. Например, в Scala вы должны использовать объект вместо класса. Хотя поведение этого очень похоже на использование статических методов в классе в Java, характер реализации сильно отличается.
Нет, фабрики могут находиться в состоянии. Это зависит от того, что нужно.
Я бы предположил, что создание является статическим, кажется хорошим выбором в первом случае - howwer в тот момент, когда вы пытаетесь унифицировать статику, с которой вы, как правило, сталкиваетесь с проблемами.
Убирайтесь, пока вы им не понадобятся.
Нет, factory класс по умолчанию не должен быть статическим. На самом деле, статические классы не приветствуются в мире ООП, поскольку они также могут передавать некоторые состояния и, следовательно, внедрять глобальное состояние приложения. Если вам нужен только один объект factory, который может присутствовать, вы можете управлять его созданием с помощью шаблона singleton.
В случае factory метода - это нормально, чтобы он был статичным (на самом деле нет другого разумного способа пойти:)).
Я предполагаю, что у моих BlueCarFactory и my RedCarFactory есть метод createCar. Это просто здравый смысл, чтобы повторно использовать фактический метод создания путем его параметризации. Затем можно было бы создать CarFactory(blue) и a CarFactory(red). Это означает, что для объекта CarFactory требуется переменная-член для хранения цвета произведенных автомобилей.
Заключение: нет смысла создавать метод класса Factory static. Имеет смысл создать объект singleton Factory.
Использование Static Method не связано с каким-либо шаблоном проектирования. Это выбор между использованием Class level или метода уровня экземпляра. Factory класс не требует поддержания какого-либо состояния. Так что обычно мы идем на Static method. Если это действительно требует state, то мы создаем объект для класса и устанавливаем состояние для объекта. На этот раз мы можем выбрать static метод или метод instance.