Абстрактная фабрика на пальцах
Написать данную статью меня заставили две причины. Совсем недавно я познакомился с паттерном Абстрактная фабрика. Как говорится – «Не умеешь сам, научи товарища». Известно, что один из лучших способов закрепления материала – это объяснение кому-либо ранее изученного. Вторая причина – в процессе изучения данного паттерна я не встретил материала, который лично для меня излагал бы вполне ясно суть Абстрактной фабрики (по крайней мере на Хабре).
Итак, приступим. Самый первый вопрос, на который нужно ответить самому себе, изучая данный паттерн: «Что же такое Абстрактная фабрика». Самый простой и точный ответ, гласит, что Абстрактная фабрика – это «фабрика фабрик». Но здесь появляется второй вопрос: «Для чего вообще может кому-нибудь понадобиться «фабрика фабрик»? Чтобы на него ответить рассмотрим пример из реальной жизни.
Допустим, вы решили полностью взять под свой контроль рынок автомобилей. Как это сделать? Вы можете создать свою марку автомобиля, своё производство, провести масштабную рекламную компанию и т.д. Но, в этом случае вам придётся сражаться с такими гигантами авторынка, как Toyota или Ford. Не факт, что из данной борьбы вы выйдите победителем. Гораздо лучшим решением будет скупить заводы всех этих компаний, продолжить выпускать автомобили под их собственными марками, а прибыль класть себе в карман. Если я не ошибаюсь, такая структура в экономике называется – холдинг. Вот этот холдинг и будет Абстрактной фабрикой или «фабрикой фабрик». В нашей программе Абстрактная фабрика (холдинг) будет представлена интерфейсом или абстрактным классом. Предприятия, входящие в холдинг, представлены классами, реализующими данный интерфейс.
public interface CarsFactory < >public class ToyotaFactory implements CarsFactory <> public class FordFactory implements CarsFactory <> Далее, вы собираете управляющих вашими фабриками и говорите: «Отныне на наших фабриках мы будем делать автомобили с 2 типами кузова – седан и купе. Например, японцы будут делать ToyotaSedan и ToyotaCoupe, американцы — FordSedan и FordCoupe». А чтобы на фабриках не забыли, что именно нужно производить, и не начали делать, например, внедорожники, повесим общие чертежи седана и купе в офисе нашего холдинга на самом видном месте (на конкретной фабрике инженеры сами разберутся как именно им делать нужные автомобили). Таким образом, в нашем интерфейсе CarsFactory появляются 2 метода:
public interface CarsFactory
Соответственно, в дочерних классах интерфейса CarsFactory, данные методы тоже должны быть реализованы.
public class ToyotaFactory implements CarsFactory < @Override public Sedan createSedan() < return new ToyotaSedan(); >@Override public Coupe createCoupe() < return new ToyotaCoupe(); >> public class FordFactory implements CarsFactory < @Override public Sedan createSedan() < return new FordSedan(); >@Override public Coupe createCoupe() < return new FordCoupe(); >> Обратите внимание, что типом возвращаемого значения в методах будет являться именно общий для возвращаемых значений тип – sedan и coupe. Возвращаясь к нашей аналогии — вы сказали фабрике сделать седан – вам сделали седан. Особенности, например, седана марки Ford, вас не интересуют.
Как несложно догадаться из приведённого кода, у нас в программе должны появится некие сущности, описывающие конкретные типы кузова – седан и купе. Такими сущностями будут интерфейсы.
public interface Sedan <> public interface Coupe <> Ну и конечно же, данные чертежи должны иметь конкретное воплощение в виде автомобилей, создаваемых на той или иной фабрике.
public class ToyotaCoupe implements Coupe < public ToyotaCoupe() < System.out.println("Create ToyotaCoupe"); >> public class ToyotaSedan implements Sedan < public ToyotaSedan() < System.out.println("Create ToyotaSedan"); >> public class FordCoupe implements Coupe < public FordCoupe () < System.out.println("Create FordCoupe"); >> public class FordSedan implements Sedan < public FordSedan() < System.out.println("Create FordSedan"); >> Вот и всё, наша «фабрика фабрик» способная производить автомобили любой марки и любого типа, готова. В будущем вы можете решить, что было бы неплохо начать выпускать внедорожники. Вам нужно будет создать ещё один интерфейс, а в офисе холдинга повесить чертёж внедорожника (добавить в CarsFactory нужный метод и реализовать его в дочерних фабриках). Так же возможно, что вы решите захватить ещё один кусок рынка и купить, например, все заводы Nissan. Это означает, что вам нужно создать ещё один класс, реализующий CarsFactory – NissanFactory, и начать выпускать ваши автомобили под этой маркой (NissanCoupe, NissanSedan и т.д.)
Но как будет взаимодействовать конкретный пользователь (покупатель автомобиля) с нашим холдингом? Покупатель вообще знать не знает о том, что вы захватили все фабрики мира по производству автомобилей. Он приходит в маленький скромный офис холдинга и говорит: «Мне нужен автомобиль!» «Отлично!» — говорим мы ему, — «вы обратились по адресу! Фабрика фабрик – это то, что вам нужно!»
«Автомобили какой фирмы предпочитаете в данное время суток?», — спрашиваем мы. Допустим, покупатель хочет приобрести тойоту. Нет проблем!
factory = new ToyotaFactory();«А какой тип кузова вы бы хотели?» Допустим – седан. «Прекрасный выбор!»
Abstract Factory Pattern in Java
Repeatedly, code that works in dev breaks down in production. Java performance issues are difficult to track down or predict.
Simply put, Digma provides immediate code feedback. As an IDE plugin, it identifies issues with your code as it is currently running in test and prod.
The feedback is available from the minute you are writing it.
Imagine being alerted to any regression or code smell as you’re running and debugging locally. Also, identifying weak spots that need attending to, based on integration testing results.
Of course, Digma is free for developers.
As always, the writeup is super practical and based on a simple application that can work with documents with a mix of encrypted and unencrypted fields.
We rely on other people’s code in our own work. Every day.
It might be the language you’re writing in, the framework you’re building on, or some esoteric piece of software that does one thing so well you never found the need to implement it yourself.
The problem is, of course, when things fall apart in production — debugging the implementation of a 3rd party library you have no intimate knowledge of is, to say the least, tricky.
Lightrun is a new kind of debugger.
It’s one geared specifically towards real-life production environments. Using Lightrun, you can drill down into running applications, including 3rd party dependencies, with real-time logs, snapshots, and metrics.
Learn more in this quick, 5-minute Lightrun tutorial:
Slow MySQL query performance is all too common. Of course it is. A good way to go is, naturally, a dedicated profiler that actually understands the ins and outs of MySQL.
The Jet Profiler was built for MySQL only, so it can do things like real-time query performance, focus on most used tables or most frequent queries, quickly identify performance issues and basically help you optimize your queries.
Critically, it has very minimal impact on your server’s performance, with most of the profiling work done separately — so it needs no server changes, agents or separate services.
Basically, you install the desktop application, connect to your MySQL server, hit the record button, and you’ll have results within minutes:
DbSchema is a super-flexible database designer, which can take you from designing the DB with your team all the way to safely deploying the schema.
The way it does all of that is by using a design model, a database-independent image of the schema, which can be shared in a team using GIT and compared or deployed on to any database.
And, of course, it can be heavily visual, allowing you to interact with the database using diagrams, visually compose queries, explore the data, generate random data, import data or build HTML5 database reports.
Get started with Spring 5 and Spring Boot 2, through the Learn Spring course:
> CHECK OUT THE COURSE
1. Overview
In this article, we’ll discuss the Abstract Factory design pattern.
The book Design Patterns: Elements of Reusable Object-Oriented Software states that an Abstract Factory “provides an interface for creating families of related or dependent objects without specifying their concrete classes”. In other words, this model allows us to create objects that follow a general pattern.
An example of the Abstract Factory design pattern in the JDK is the newInstance() of javax.xml.parsers.DocumentBuilderFactory class.
2. Abstract Factory Design Pattern Example
In this example, we’ll create two implementations of the Factory Method Design pattern: AnimalFactory and ColorFactory.
After that, we’ll manage access to them using an Abstract Factory AbstractFactory:
First, we’ll create a family of Animal class and will, later on, use it in our Abstract Factory.
Here’s the Animal interface:
and a concrete implementation Duck:
public class Duck implements Animal < @Override public String getAnimal() < return "Duck"; >@Override public String makeSound() < return "Squeks"; >> Furthermore, we can create more concrete implementations of Animal interface (like Dog, Bear, etc.) exactly in this manner.
The Abstract Factory deals with families of dependent objects. With that in mind, we’re going to introduce one more family Color as an interface with a few implementations (White, Brown,…).
Now that we’ve got multiple families ready, we can create an AbstractFactory interface for them:
public interface AbstractFactory
Next, we’ll implement an AnimalFactory using the Factory Method design pattern that we discussed in the previous section:
public class AnimalFactory implements AbstractFactory < @Override public Animal create(String animalType) < if ("Dog".equalsIgnoreCase(animalType)) < return new Dog(); >else if ("Duck".equalsIgnoreCase(animalType)) < return new Duck(); >return null; > > Similarly, we can implement a factory for the Color interface using the same design pattern.
When all this is set, we’ll create a FactoryProvider class that will provide us with an implementation of AnimalFactory or ColorFactory depending on the argument that we supply to the getFactory() method:
public class FactoryProvider < public static AbstractFactory getFactory(String choice)< if("Animal".equalsIgnoreCase(choice))< return new AnimalFactory(); >else if("Color".equalsIgnoreCase(choice)) < return new ColorFactory(); >return null; > >3. When to Use Abstract Factory Pattern:
- The client is independent of how we create and compose the objects in the system
- The system consists of multiple families of objects, and these families are designed to be used together
- We need a run-time value to construct a particular dependency
While the pattern is great when creating predefined objects, adding the new ones might be challenging. To support the new type of objects will require changing the AbstractFactory class and all of its subclasses.
4. Summary
In this article, we learned about the Abstract Factory design pattern.
Finally, as always, the implementation of these examples can be found over on GitHub.
Slow MySQL query performance is all too common. Of course it is. A good way to go is, naturally, a dedicated profiler that actually understands the ins and outs of MySQL.
The Jet Profiler was built for MySQL only, so it can do things like real-time query performance, focus on most used tables or most frequent queries, quickly identify performance issues and basically help you optimize your queries.
Critically, it has very minimal impact on your server’s performance, with most of the profiling work done separately — so it needs no server changes, agents or separate services.
Basically, you install the desktop application, connect to your MySQL server, hit the record button, and you’ll have results within minutes: