Builder class in android

Java. Шаблон Builder

Шаблон не является частью языка Java, это рекомендация умных программистов для создания эффективных решений во время разработки сложных проектов.

Если ваш класс содержит большое количество конструкторов и статических методов, то возникает проблема — трудно запомнить порядок и назначение необязательных параметров при вызове класса. В таких случаях рекомендуется использовать шаблон Builder.

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

Создание экземпляра класса с использованием конструктора со всем набором параметров.

Глядя на набор чисел, трудно понять код. Правда, на данный момент студия выводит подсказку прямо в редакторе, что упростило задачу. Но этот же код, опубликованный на сайте, не будет содержать подобных подсказок, поэтому проблема остаётся. Кроме того, увеличение числа параметров только усложняет сопровождение кода.

Можно прибегнуть к другому варианту — вызвать конструктор без параметров, чтобы создать объект, а затем вызывать сеттеры для установки обязательных и некоторых необязательных параметров.

Количество кода в классе увеличивается, но код стал более читаемым при создании экземпляра класса.

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

Поэтому был придуман третий вариант, который назвали шаблоном Builder. Вместо непосредственного создания объекта класса вызывается конструктор (или статический метод) со всеми необходимыми параметрами, чтобы получить объект Builder. Затем вызываются сеттеры для установки всех необходимых параметров. В завершение, вызывается метод build() для генерации объекта, который будет являться неизменным. Реализуется такой подход через статический внутренний класс.

Создадим уже «хороший» класс с применением Builder.

Класс GoodClass является неизменным и все значения параметров по умолчанию находятся в одном месте. Сеттеры возвращают класс-строитель, поэтому вызовы можно объявлять в цепочку.

При таком подходе код проще писать и легко читать. У шаблона есть и другие преимущества, например, можно задействовать несколько параметров varags.

Недостатком шаблона является затраты на создание класса Builder, но если вы будете позже расширять класс, то подход оправдает себя.

Создавайте Builder в том случае, когда параметров четыре и больше. В остальных случаях используйте традиционный подход.

Источник

Элегантный Builder на Java

Наверняка большинство сколько-нибудь опытных программистов знакомы с паттерном Builder. Он позволяет сделать инициализацию структур данных более наглядной, гибкой при этом сохраняя такое полезное их свойство как неизменяемость (immutability). Вот классический пример с первой страницы выдачи гугла на запрос «java builder pattern example». При всех своих преимуществах, самый главный недостаток данной реализации паттерна — в два раза больше кода, по сравнению с обычным плоским бином. Если генерация этого дополнительного кода не проблема для любой популярной IDE, то редактировать такой класс становится достаточно утомительно и читабельность страдает в любом случае.

В какой-то момент я решил, что хватит это терпеть и занялся поисками альтернативы. Надо сказать, альтернатива нашлась достаточно быстро. В Java есть редко использующийся механизм нестатических внутренних классов. Экземпляр такого класса можно создать только через экземпляр класса-родителя с помощью оператора .new. Что важно, такой объект имеет доступ к приватным полям своего родителя.

Итак, у нас есть неизменяемая структура

Здесь сейчас всего два поля, но билдер все равно был бы полезен чтобы не путать порядок параметров в конструкторе и если понадобится проинициализировать только одно поле из двух или оба, но в разные моменты времени. Что говорить, когда полей станет 20!

Чтобы не дублировать поля в классе-билдере, просто заводим внутренний класс. Он имеет доступ к приватным полям своего родительского класса и может выставлять их напрямую. Собственный конструктор класса сделаем приватным, а с полей уберем модификатор final.

Конструктор у билдера тоже приватный, иначе имея доступ к экземляру Account можно было бы сделать билдер и через него изменять поля уже созданного объекта. Метод build просто возвращает уже готовый объект (здесь можно проверять все ли обязательные поля на месте, например.

Последний штрих — добавляем в метод для создания экземпляра билдера.

Сравните с традиционной реализацией:

Попробуйте добавить новое поле или изменить тип поля token в том и другом случае. С увеличением количества полей разница в объеме кода и читабельности будет все более заметной. Сравним пример из статьи, на которую я ссылался в начале топика (я его изменил, чтобы стили примеров совпадали):

И реализация через внутренний класс:

Можно заметить, что с точки зрения организации кода такой класс отличается от обычного плоского бина с полями и гетерами-сетерами только тем, что сеттеры сгруппированы в отдельном внутреннем классе, добавились только пара методов newBuilder() и build(), строчка с объявлением внутреннего класса и приватные конструкторы.

1. Метод build билдера возвращает один и тот же объект и если после его вызова продолжить выставлять поля через методы билдера, поля уже созданного объекта будут меняться. Это легко исправить, если создавать каждый раз новый экземпляр объекта:

При этом возвращается часть дублирующего кода, от которого мы пытались избавиться. Обычно ссылка на билдер не покидает метод, поэтому я предпочитаю вариант, который показал сначала. Если вы часто передаете билдер туда-сюда и переиспользуете его для повторной генерации объектов, используйте вариант, как показано выше.

2. Спасибо комментаторам, мои сомнения развеяны — объект, получаемый из такого билдера, не потокобезопасен из-за того, что поля в нем не объявлены как final. Если в вашем приложении важен этот момент, лучше использовать классический билдер.

И напоследок — использование билдера.

Опять же Account.newBuilder() моим программерским глазам милее, чем new Account.Builder(), хотя это уже дело вкуса.

Всем чистого кода!

UPD: Как часто бывает на хабре, комментарии оказались полезнее самого топика, рекомендуются к ознакомлению.

Источник

Design Patterns in Android – Builder

Design patterns are reusable solutions to the most commonly occurring software problems. Let’s take a look at the Builder pattern in Android!

Paulina Szklarska Android Developer

Design patterns are reusable solutions to the most commonly occurring software problems. They can speed up the development process by providing a proven way of resolving frequent issues. Discover Builder, which is one of the most common design patterns, and check out some examples of Android implementations in practice!

Introduction

Design patterns can be divided into three sections:

• Creational Design Patterns deliver solutions for creating classes and objects (Singleton, Factory, Builder, etc.)
• Structural Design Patterns relate to the arrangement of classes and objects (e.g. Composite, Facade, Adapter)
• Behavioral Design Patterns give us ways to communicate between objects and classes (Command, Observer, Strategy, etc.)

Drive Your Product to Success – Free Guide for Digital Product Owners

Even the best team can’t deliver a successful product without proper guidance. If you own a digital product, our Ebook will be a perfect resource for mastering the fundamentals of successful product delivery.

Builder

The Builder pattern simplifies object creation in a very clean and readable way. It’s very helpful when we have some model classes with many parameters. We can make some of them optional, or required, and we don’t force the user to use a specific order (as found in the constructor). By using this Builder pattern, the result is an elegant chain of methods.

Источник

Create complex object at run-time with Builder pattern

May 25, 2017 · 3 min read

A design pattern is a well described solution to a common software problem. It also helps to prevent subtle issues that can cause major problems and improves code readability with the patterns.

The Builder is a creational pattern. With Builder pattern we can separate the construction of a complex object from its representation and build different objects using same construction process. Builder pattern is more likely implemented using method cascading.

As mentioned in the Gang of four —

“Separate the construction of a complex object from its representation so that the same construction process can create different representations.”

Where to use?

Following are the conditions which we can easily handle using builder design pattern-

1. When multiple representation of objects are required.

2 . Too many argument to pass from client.

3. Object creation contains optional parameter.

What problem it solve?

We all know each class has a constructor in Java and if we don’t explicitly declare a constructor of a class then compiler builds a default constructor for that class. We can also create parameterized constructor which can take different parameters required to create an object.

Problem starts when an object can be created with lot of parameters and some of them may be mandatory and others may be optional.

In general we pass the NULL values for the optional parameters or overload more constructors to create a desired object of a class. Situation become more error prone when many fields has same type and we confused with their order while passing the values to the constructor.

To create an object of Employee class, we must pass all the values of parameters to its constructor. It will look like this:

Now what if only id, firstName and lastName are mandatory and rest fields are optional then object generation looks like-

Any like many more constructor…

The problem with above approach is that the object state will be inconsistent during building. Here builder design pattern will help you to achieve the goal.

How builder works

Below are the steps required to create a builder pattern:

• Create a builder class with all the required fields.
• Builder class should have a public constructor with all the required parameters.
• Create methods to get the values of optional parameters. These methods should return the same builder object after setting the optional attribute.
• Finally provide a build() method in the builder class which will return the desired object.

Here is the sample builder pattern example code where we have Employee class and EmployeeBuilder class to build it.

You can get the complete example code from GitHub.

And below is the way, we will use the EmployeeBuilder in our code:

Notice that Employee class has only no public constructor and buildEmployee() method in the EmployeeBuilder class is the only way to create Employee object.

Examples in JDK

Builder pattern is also used in Java classes like —

Conclusion

Using builder design patter we can have more maintainable code if number of fields required to create object is increased. It also reduce the chance to pass invalid values because of explicit optional method calls.

Thanks for reading. To help others please click ❤ to recommend this article if you found it helpful.

Stop of being selfish, spread the knowledge

Stay tuned for upcoming articles. For any quires or suggestions, feel free to hit me on Twitter Google+

Check out my blogger page for more interesting topics on Software development.

Источник

What is Builder class in Android and what is its purpose?

I was working on NotificationManager but i can’t understand the purpose of builder. Notification n = new Notification.Builder(this)

2 Answers 2

Builder isn’t something specific to the Android environment, as it is a design pattern. The Notification class just happens to use that pattern.

As you can see on the Notification docs:

The Notification.Builder has been added to make it easier to construct Notifications.

And that is what Builder is all about. To make things easier.

The sole purpose of such a pattern is to to separate the construction of a complex object from its representation. As stated on oopaterns website:

This pattern allows a client object to construct a complex object by specifying only its type and content, being shielded from the details related to the object’s representation.

So instead of calling a constructor with a lot of arguments, you create a builder, and fine tune it with the parameters you need, then you’ll call the build() method to create the object you need.

It also helps when you have predefined object templates, and you can use the builder pattern to instantiate such objects without having to pass arguments to it.

You can read more about that on this tutorial.

Источник