Можно ли объяснить разницу между factory и шаблонами стратегии?
Для меня оба выглядят так же, как и дополнительный класс factory (который создает объект продукта в шаблонах factory)
Можно ли объяснить разницу между factory и шаблонами стратегии?
Для меня оба выглядят так же, как и дополнительный класс factory (который создает объект продукта в шаблонах factory)
A factory pattern - это шаблон создания. Шаблон стратегии - это операционная схема. Другими словами, для создания объектов определенного типа используется шаблон factory. Шаблон стратегии используется для выполнения операции (или набора операций) определенным образом. В классическом примере factory может создавать разные типы животных: Dog, Cat, Tiger, в то время как шаблон стратегии будет выполнять определенные действия, например Move; используя стратегии Run, Walk или Lope.
Фактически эти два могут использоваться вместе. Например, у вас может быть factory, который создает ваши бизнес-объекты. Он может использовать разные стратегии, основанные на среде сохранения. Если ваши данные хранятся локально в XML, он использует одну стратегию. Если данные были удалены в другой базе данных, он использовал бы другой.
Шаблон стратегии позволяет полиморфно изменять поведение класса.
Шаблон factory позволяет инкапсулировать создание объекта.
Гэри делает замечательный момент. Если вы используете принцип кодирования для абстракций, а не для "конкреций", тогда многие шаблоны начинают выглядеть как вариации в теме.Чтобы добавить к сказанному tvanfosson, многие шаблоны выглядят одинаково с реализацией. То есть, вы создали интерфейс, в котором, возможно, не было ни одного в вашем коде, а затем создайте кучу реализаций этого интерфейса. Разница заключается в их предназначении и способах их использования.
Создавайте только конкретные экземпляры. Различные аргументы могут приводить к различным объектам. Это зависит от логики и т.д.
Инкапсулируйте алгоритм (шаги) для выполнения действия. Таким образом, вы можете изменить стратегию и использовать другой алгоритм.
В то время как оба выглядят очень похожими, цель совсем другая, одна цель - создать другую, чтобы выполнить действие.
Итак. Если ваш метод Factory исправлен, возможно, он выглядит следующим образом:
public Command getCommand( int operatingSystem ) {
switch( operatingSystem ) {
case UNIX :
case LINUX : return new UnixCommand();
case WINDOWS : return new WindowsCommand();
case OSX : return new OSXCommand();
}
}
Но предположим, что ваш Factory нуждается в более продвинутом или динамическом создании. Вы можете добавить к методу Factory стратегию и изменить ее, не перекомпилируя, стратегия может измениться во время выполнения.
Прежде всего необходимо сделать разницу между простыми factory и абстрактными factory. Первый - простой factory, где у вас есть только один класс, который действует как factory для создания объекта, а в последнем вы подключаетесь к интерфейсу factory (который определяет имена методов), а затем вызываете разные которые реализуют этот интерфейс, которые должны иметь разные реализации одного и того же метода, основанные на некоторых критериях. Например, у нас есть интерфейс ButtonCreationFactory, который реализован двумя фабриками, первый WindowsButtonCreationFactory (создает кнопки с внешним видом Windows) и второй LinuxButtonCreationFactory (создает кнопки с внешним видом Linux). Таким образом, обе эти фабрики имеют один и тот же метод создания с различными реализациями (алгоритмами). Вы можете ссылаться на это во время выполнения на основе метода, который вы набираете нажатием кнопки, которую вы хотите.
Например, если вы хотите, чтобы кнопки с Linux выглядели и выглядели:
ButtonCreationFactory myFactory = new LinuxButtonCreationFactory();
Button button1 = myFactory.createButton(...);
или если вы хотите использовать кнопки Windows
ButtonCreationFactory myFactory = new WindowsButtonCreationFactory();
Button button1 = myFactory.createButton(...);
Именно в этом случае он приводит к своего рода шаблону стратегии, поскольку он отличает алгоритмы для создания некоторого создания. Однако он отличается от него семантически, потому что он используется для OBJECT CREATION, а не для операционных алгоритмов. Итак, в основном с абстрактным factory у вас есть создание объекта с использованием разных стратегий, что делает его очень похожим на шаблон стратегии. Однако AbstractFactory является творческим, а шаблон стратегии работает. Реализация мудрая, они должны быть одинаковыми.
Factory (и FactoryMethod возвращается Factory):
Посмотрите на статью в википедии и javarevisited article
Стратегия стратегии:
Пример:
Вы можете настроить стратегию скидок для определенного элемента (билет AirFare или элемент ShoppingCart). В этом примере вы предложите скидку 25% на товар в течение июля - декабря и без скидки на товар во время Jaunary - June.
Похожие сообщения:
Реальный мир Пример шаблона стратегии
Шаблоны проектирования: Factory vs Factory метод vs Аннотация Factory
Чтобы распространить то, что сказал Оскар, и в отношении его кода:
getCommand - это классы Factory, а классы UnixCommand, WindowsCommand и OSXCommand - это стратегии
Стратегический шаблон в простых терминах - это скорее создание поведения, когда вы не занимаетесь классом внедрения. С другой стороны, factory представляет собой создание экземпляра конкретного класса конкретного экземпляра, и вам решать использовать любое поведение (метод), открытое реализованным интерфейсом.
Я могу отвлечься от Оскара, потому что его пример реализации Factory довольно тесно связан и очень закрыт, неудивительно, что ваш выбор - шаблон стратегии. Реализация Factory не должна зависеть от какого-либо фиксированного числа экземпляров определенных экземпляров, например:
public Command getCommand( int operatingSystem ) {
return commandTable.get(operatingSystem);
}
...
public class WindowsCommand implements Command {
...
static {
CommandTable.getInstance().registerCommand(WIN_COMMAND_ID, new WindowsCommand());
}
}
Я думаю, что наиболее подходящими критериями для выбора того или другого являются в основном те термины, которые вы используете для обозначения своих классов и методов, принимая во внимание, что мы все должны стремиться программировать к интерфейсам, а не к классам, а также фокусироваться на цели: мы чтобы определить, какой код будет выполняться во время выполнения. Тем не менее, мы можем достичь цели, используя любой из двух шаблонов.
Стратегия и Factory - разные цели. В стратегии у вас есть определенный подход, используя этот шаблон, вы можете изменить поведение (алгоритмы). Приходя к Factory, вокруг много вариантов. Но исходный шаблон из состояний GO4 Factory оставляет создание объекта для дочернего класса. Здесь с Factory вы заменяете полный экземпляр, а не поведение, которое вас интересует. При этом вы будете заменять полную систему, а не алгоритм.
Factory pattern - это шаблон создания, который создается с указанными свойствами (поведением). а во время выполнения после создания и не изменяйте его свойства (поведение). поэтому, если вам нужны разные свойства (поведение), вы должны удалить объект и создать новый объект с необходимыми свойствами (поведением). который не является гудом. в то время как в случае шаблона стратегии u может изменять свойства (поведение) во время выполнения.
Вы не можете понять разницу, просто взглянув на код или категоризацию. Чтобы правильно понять шаблоны GoF, посмотрите их намерения:
Стратегия: "Определите семейство алгоритмов, инкапсулируйте каждый из них и сделайте их взаимозаменяемыми. Стратегия позволяет алгоритму независимо варьироваться от клиентов, которые его используют".
Factory Метод: "Определите интерфейс для создания объекта, но пусть подклассы решают, какой класс должен быть создан. Factory Метод позволяет классу отложить создание экземпляров подклассов".
И вот подробное объяснение намерений и различий между этими двумя шаблонами: Разница между Factory Шаблонами проектирования методов и стратегий