- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
package org.trishinfotech.builder;
public class Car {
private String chassis;
private String body;
private String paint;
private String interior;
public Car() {
super();
}
public Car(String chassis, String body, String paint, String interior) {
this();
this.chassis = chassis;
this.body = body;
this.paint = paint;
this.interior = interior;
}
public String getChassis() {
return chassis;
}
public void setChassis(String chassis) {
this.chassis = chassis;
}
public String getBody() {
return body;
}
public void setBody(String body) {
this.body = body;
}
public String getPaint() {
return paint;
}
public void setPaint(String paint) {
this.paint = paint;
}
public String getInterior() {
return interior;
}
public void setInterior(String interior) {
this.interior = interior;
}
public boolean doQualityCheck() {
return (chassis != null && !chassis.trim().isEmpty()) && (body != null && !body.trim().isEmpty())
&& (paint != null && !paint.trim().isEmpty()) && (interior != null && !interior.trim().isEmpty());
}
@Override
public String toString() {
// StringBuilder class also uses Builder Design Pattern with implementation of java.lang.Appendable interface
StringBuilder builder = new StringBuilder();
builder.append("Car [chassis=").append(chassis).append(", body=").append(body).append(", paint=").append(paint)
return builder.toString();
}
}
Follow us!
Вот такой это builder.
Вообще, мне кажется, что как в некоторых числовых последовательностях закладывается избыточность для выявления очепяток, так и в йаже введён специфический избыточный синтаксис с гротескными и гипертрофированными паттернами, чтобы даже САМЫЙ тупой джавист мог писать код с минимальным количеством ошибок.
Паттерн билдер вроде же должен иметь метод `build()', возвращающий инстанс другого класса.
Вот твой билбер.
А класс выше – это так, бойлерплейт для этого билбера.
Весь простенький пример паттерня Строитель в той статье состоит из 283 строк. Ня влез ≡(▔﹏▔)≡.
Никто не хочет приводить реальный пример системы, в которой применение паттерна помогло сделать код понятнее. Ссылку на какую-нибудь репу, где это реально юзается, к примеру.
Поправил. Потому что в вузе нам преподавали ТРИЗ, тот самый, в котором лучшая система та, которой нет. Именно поэтому я не пользуюсь паттернами, а просто дописываю питушню в funkcii.php и теку, значит паттерны не нужны!
Пусть кинут ссылку на какую-нибудь нибудь реальную репу где баг воспроизводится
10% — Issue закрыт с причиной "хз, вроде всё нормально, баг где-то у вас" или "я ебал настраивать билд систему для вашего проекта и собирать его, чтобы проверить существование бага."
Проблема в том, что код нужно комментировать, место в книге денег стоит, а кидать ссылку на репу — свинство по отношению к тем, кто решил почитать книгу, пересекая Тихий океан.
но дело не в этом, если вербозность не влезает в книгу, то такая книга нахуй не нужна
всякие приложения к книге не должны становиться неотъемлемой частью
Ок, принято. А как понять, когда я реально его должен юзать?
З.Ы. Я не утверждаю, что простые примеры надо выбросить. Я утверждаю, что надо дополнять их реальными примерами, где можно вникнуть в чужой код и увидеть паттерн на практике.
Нужно конечно и то, и то: и пример кода (который умещается на один экран) и реальный пример.
Да не напишешь ты это словами... Так потом и рождаются джависты, которые срут паттернами и лепят из них архитектуру, не понимая зачем они это делают.
Например, разрабатывать большой проект, и в каждом паттерне писать сначала простой пример, а потом как он вписывается в проект.
Если я хочу быстро узнать патттерн, то мне нет смысла вникать в проект: я обычно уже и так понимаю зачем мне паттерн нужен. А если я изучаю его с ноля, то да, нужно показывать реальный пример.
Я ещё ни в одной статье не видела внятного ответа на вопрос "а нахуя?"
Нинужный костыль для убогих оопшных язычков, которые умеют диспатчить только по первому аргументу.
Хорошая альтернатива визитору это pattern matching с exhausted when + sealed classed в коко
Давайте угадывать кто и как оскорбился на слово «Wheel».
Напоминает дешевые SEO тексты:
"Как покрасить стену?
Безусловно, каждому из нас рано или поздно приходится сталкиваться с вопросом: как покрасить стену?
Чтобы ответит на такой важный вопрос, как покрасить стену, предлагается прочитать вот эту статью, которая кстати так и накзывается: как покрасить стену"
petuh.setIq(-1).setName("dzhavist")
между строками
employee->age = 99;
и
employee->salary = 100;
может быть куча кода!
Типа
employee->salary = 25;
return;
?
любая логика
Например:
r = request.addDetail("koko")
if (len == 1):
. . . . r.addDetail("ololo").fire()
else:
. . . . r.removeDetail("defolt").addCode(200).fi re()
Да не, вот например какой-нибудь построитель запросов -- хороший, годный пример билдера.
Я пишу что-то в духе query.where(employee.name, "bormand").all() и мне пофиг, как билдер это будет переводить на конкретный диалект "SQL" (или даже "NoSQL").
Вот оно, то самое разделение между "что построить" и "как построить".
На собеседованиях уже никто не спрашивает?
Но перед собеседами я обычно тренировал алгоритмы, их сложнее вспомнить, чем паттрены. Правда все равно ничего слоднее qsort и binary search на обычных работах не спрашивают
Мое представление о дизайне примерно на уровне вот
Напишешь с первого раза, нигде не залетев на единичку и не соснув UB'ца?
Но не всегда просят писать: иногда просто нужно рассказать какие есть виды поиска, какие у них требования к данным, и какие большие О
оно, кстати, зависит от сортированности говна изначально
это худшее же. Его можно шафлнуть, чтобы такого говна не получить вроде (если не путаю)
А про сортировку слиянием помнишь?
В частности в джаве для примитивов ку, а для объектов был merge, но теперь там есть еще TimSort.
как эта хрень работает?
там как-то оператор == перегружен и чото такое возвращает?
Да.
В джанге это более попидарски, типа
Кстати, ты умеешь пользоваться гибридными атрибутами в SQLAlchemy?
Это, имхо, самая киллер фича по сравнению с джангой
если у тебя таких полей 22, то ты будешь 22 поля копипастить?
В примере с джавой -- паста. Правда это паста в ОДНОМ месте, а не во всех местах использования.
Алсо, см пример емейлпротектда с передачей билдера
Вот если бы там в структуре были какие-то методы, то да: без отдельного билдера бы не получилось, пушо пока билд не закончен объект не консистентен, и методы вызвать нельзя
https://twitter.com/Jetskigrizzly/status/1382712270677942276
на практике получение произвольного кол-ва данных из прошлого обсера звучит сомнительно
Правда конечно нужно гарантировать, что он подключится, иначе там буфер раздуется
Хотя.. он же навсегда закеширует ВСЕ данные?
Но чтобы нужно было хранить стейт обсервера между подключениями не припомню, разве что для расширения хрома где хуй знает когда что на страницу подгрузится
https://caizcoin.com/
Можня было ня писать лишний конструктор, а проставить default-аргументы (Котлин бы сам сгенерировал отдельный Car(), кстати), но оригинал ня мог принимать ня все параметры, так что и мы ня будем.
В оригиняле, кстати, автор так вдохновился крутым "Builder Design Pattern" в toString(), что забыл поставить закрывающую квадратную скобку: видимо, от количества бойлерплейта, которого ему пришлось написать, мозг нямножко разжижился.
Не хотел бы иметь возможность вызывать его методы
Но да, без nullable этот класс в Котлине будет ещё няшнее.
А на TS сделать (как и на крестах)