Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Вообще, мне кажется, что как в некоторых числовых последовательностях закладывается избыточность для выявления очепяток, так и в йаже введён специфический избыточный синтаксис с гротескными и гипертрофированными паттернами, чтобы даже САМЫЙ тупой джавист мог писать код с минимальным количеством ошибок.
Кстати, почему паттерны всегда объясняют на каких-то тривиальных примерах, где они нафиг не сдались?
Никто не хочет приводить реальный пример системы, в которой применение паттерна помогло сделать код понятнее. Ссылку на какую-нибудь репу, где это реально юзается, к примеру.
Поправил. Потому что в вузе нам преподавали ТРИЗ, тот самый, в котором лучшая система та, которой нет. Именно поэтому я не пользуюсь паттернами, а просто дописываю питушню в funkcii.php и теку, значит паттерны не нужны!
90% случаев — баг в проприетарщиене, которую без согласования со спортлото в нормальном объёме не покажешь.
10% — Issue закрыт с причиной "хз, вроде всё нормально, баг где-то у вас" или "я ебал настраивать билд систему для вашего проекта и собирать его, чтобы проверить существование бага."
У GoF вроде в начале книги было описание рахитектуры текстового редактора с использованием паттернов.
Проблема в том, что код нужно комментировать, место в книге денег стоит, а кидать ссылку на репу — свинство по отношению к тем, кто решил почитать книгу, пересекая Тихий океан.
для этого есть inmarsat
но дело не в этом, если вербозность не влезает в книгу, то такая книга нахуй не нужна
всякие приложения к книге не должны становиться неотъемлемой частью
Ок, принято. А как понять, когда я реально его должен юзать?
З.Ы. Я не утверждаю, что простые примеры надо выбросить. Я утверждаю, что надо дополнять их реальными примерами, где можно вникнуть в чужой код и увидеть паттерн на практике.
так нет, можно и кодом показать, но это нужно делать параллельно.
Например, разрабатывать большой проект, и в каждом паттерне писать сначала простой пример, а потом как он вписывается в проект.
Если я хочу быстро узнать патттерн, то мне нет смысла вникать в проект: я обычно уже и так понимаю зачем мне паттерн нужен. А если я изучаю его с ноля, то да, нужно показывать реальный пример.
Х.з., я бы вот лучше реальные примеры покурил чтобы прочувствовать пользу от паттерна и увидеть, как красиво он встроен в код. Это особо много времени не займёт если автор указал на все интересные моменты.
З.Ы. Ну вот зачем, к примеру, автор статьи рассказывает об иммутабельном Employee и билдере для него? Какую задачу ему поможет решить эта иммутабельность. В джаве.
Я ещё ни в одной статье не видела внятного ответа на вопрос "а нахуя?"
ну вообще билдер позволяет разнести код сборки объекта в разные места, но при этом сохранить иммутабельность, которая гарантирует тебе некоторый инвариант класса (иначе ты будешь постоянно не понимать в каком он состоянии)
Действительно, если можно было бы диспатчить по типу аргумента в рантайме (а не только по типу объекта, сиречь первого аргумента) то визитор был бы не нужен, но только если твой язык не статически типизирован, бо визитор заставляет тебя обработать ВСЕ возможные типы, а в скриптушне это не нужно.
Хорошая альтернатива визитору это pattern matching с exhausted when + sealed classed в коко
"Как покрасить стену?
Безусловно, каждому из нас рано или поздно приходится сталкиваться с вопросом: как покрасить стену?
Чтобы ответит на такой важный вопрос, как покрасить стену, предлагается прочитать вот эту статью, которая кстати так и накзывается: как покрасить стену"
Ну вот это ближе к практике... Здесь билдер содержит в себе удобные и осмысленные методы для настройки состояния. А не просто ебучий бесполезный setField() для каждого поля.
Да не, вот например какой-нибудь построитель запросов -- хороший, годный пример билдера.
Я пишу что-то в духе query.where(employee.name, "bormand").all() и мне пофиг, как билдер это будет переводить на конкретный диалект "SQL" (или даже "NoSQL").
Вот оно, то самое разделение между "что построить" и "как построить".
Давно не менял работу)
Но перед собеседами я обычно тренировал алгоритмы, их сложнее вспомнить, чем паттрены. Правда все равно ничего слоднее qsort и binary search на обычных работах не спрашивают
Давно не менял работу)
Но перед собеседами я обычно тренировал алгоритмы, их сложнее вспомнить, чем паттрены. Правда все равно ничего слоднее qsort и binary search на обычных работах не спрашивают
Да, это правда. Просто передача билдера в функцию – очень похожа на фабричный метод. С другой стороны, можно передавать билдер в несколько функций, а это уже будет похоже на декоратор либо на интерфейсы...
Да, это правда. Просто передача билдера в функцию – очень похожа на фабричный метод. С другой стороны, можно передавать билдер в несколько функций, а это уже будет похоже на декоратор либо на интерфейсы...
User.country — объект типа Column. У Column перегружен __eq__(self, other), который возвращает какую-то штуковину, которая потом в SQL выплёвывает равенство.
Да.
User.country — объект типа Column. У Column перегружен __eq__(self, other), который возвращает какую-то штуковину, которая потом в SQL выплёвывает равенство.
Да.
Однако же решается главная задача: некую сущность удобно собрать по кусочкам, и потом сделать иммутабельной
Вот если бы там в структуре были какие-то методы, то да: без отдельного билдера бы не получилось, пушо пока билд не закончен объект не консистентен, и методы вызвать нельзя
Кэмп, если у меня Subject в rxjs получает события ДО того, как к нему присоединились обсерверы, и я хочу, чтобы они получили всё говно, что было до них, то мне подойдет ReplaySubject?
Но чтобы нужно было хранить стейт обсервера между подключениями не припомню, разве что для расширения хрома где хуй знает когда что на страницу подгрузится
Однажды хотел исправить 2/3 на 1/3, а написал почему-то 2/1. Но самое гнусное, что железяка работала, только нестабильно и не во всех режимах (там значение из-за переполнения байта не слишком отличающееся получилось). Пока не догадался частоту осциллографом померить, все мучился со всякой защитой от помех, поиском закономерностей и т.п..
class Car(
var chassis: String?,
var body: String?,
var paint: String?,
var interior: String?
) {
constructor() : this(null, null, null, null)
fun doQualityCheck() = arrayOf(chassis, body, paint, interior).all { !it.isNullOrBlank() }
override fun toString() = "Car [chassis=$chassis, body=$body, paint=$paint]"
}
Можня было ня писать лишний конструктор, а проставить default-аргументы (Котлин бы сам сгенерировал отдельный Car(), кстати), но оригинал ня мог принимать ня все параметры, так что и мы ня будем.
В оригиняле, кстати, автор так вдохновился крутым "Builder Design Pattern" в toString(), что забыл поставить закрывающую квадратную скобку: видимо, от количества бойлерплейта, которого ему пришлось написать, мозг нямножко разжижился.
ну ни на джаве ни на коко это красиво не сделать, увы
А на TS сделать (как и на крестах)
class Car {
public chassis?: string
public body?: string
build(): Readonly<NonNullable<Car>> { //убираем вопросики и делаем иммутабельными
Object.keys(this).forEach((field) => {
if (!field) {
throw new Error(`Field ${field} is not set`);
}
});
return this; //Можно еще Object.freeze
}
}
PolinaAksenova # 0
JloJle4Ka # 0 ⇈
j123123 # 0 ⇈
bormand # 0 ⇈
[email protected] # 0 ⇈
JloJle4Ka # 0
Вот такой это builder.
Вообще, мне кажется, что как в некоторых числовых последовательностях закладывается избыточность для выявления очепяток, так и в йаже введён специфический избыточный синтаксис с гротескными и гипертрофированными паттернами, чтобы даже САМЫЙ тупой джавист мог писать код с минимальным количеством ошибок.
bormand # 0
CHayT # 0
Паттерн билдер вроде же должен иметь метод `build()', возвращающий инстанс другого класса.
bormand # 0 ⇈
JloJle4Ka # 0 ⇈
Вот твой билбер.
А класс выше – это так, бойлерплейт для этого билбера.
PolinaAksenova # 0 ⇈
Весь простенький пример паттерня Строитель в той статье состоит из 283 строк. Ня влез ≡(▔﹏▔)≡.
JloJle4Ka # 0 ⇈
bormand # 0 ⇈
Никто не хочет приводить реальный пример системы, в которой применение паттерна помогло сделать код понятнее. Ссылку на какую-нибудь репу, где это реально юзается, к примеру.
JloJle4Ka # 0 ⇈
Поправил. Потому что в вузе нам преподавали ТРИЗ, тот самый, в котором лучшая система та, которой нет. Именно поэтому я не пользуюсь паттернами, а просто дописываю питушню в funkcii.php и теку, значит паттерны не нужны!
bootcamp_dropout # 0 ⇈
Пусть кинут ссылку на какую-нибудь нибудь реальную репу где баг воспроизводится
[email protected] # 0 ⇈
10% — Issue закрыт с причиной "хз, вроде всё нормально, баг где-то у вас" или "я ебал настраивать билд систему для вашего проекта и собирать его, чтобы проверить существование бага."
bootcamp_dropout # 0 ⇈
[email protected] # 0 ⇈
Проблема в том, что код нужно комментировать, место в книге денег стоит, а кидать ссылку на репу — свинство по отношению к тем, кто решил почитать книгу, пересекая Тихий океан.
gologub # 0 ⇈
но дело не в этом, если вербозность не влезает в книгу, то такая книга нахуй не нужна
всякие приложения к книге не должны становиться неотъемлемой частью
booratihno # 0 ⇈
bormand # 0 ⇈
Ок, принято. А как понять, когда я реально его должен юзать?
З.Ы. Я не утверждаю, что простые примеры надо выбросить. Я утверждаю, что надо дополнять их реальными примерами, где можно вникнуть в чужой код и увидеть паттерн на практике.
booratihno # 0 ⇈
Нужно конечно и то, и то: и пример кода (который умещается на один экран) и реальный пример.
bormand # 0 ⇈
Да не напишешь ты это словами... Так потом и рождаются джависты, которые срут паттернами и лепят из них архитектуру, не понимая зачем они это делают.
booratihno # 0 ⇈
Например, разрабатывать большой проект, и в каждом паттерне писать сначала простой пример, а потом как он вписывается в проект.
Если я хочу быстро узнать патттерн, то мне нет смысла вникать в проект: я обычно уже и так понимаю зачем мне паттерн нужен. А если я изучаю его с ноля, то да, нужно показывать реальный пример.
bormand # 0 ⇈
bormand # 0 ⇈
Я ещё ни в одной статье не видела внятного ответа на вопрос "а нахуя?"
booratihno # 0 ⇈
bormand # 0 ⇈
guest # 0 ⇈
Desktop # 0 ⇈
bormand # 0 ⇈
Нинужный костыль для убогих оопшных язычков, которые умеют диспатчить только по первому аргументу.
DypHuu_niBEHb # 0 ⇈
Хорошая альтернатива визитору это pattern matching с exhausted when + sealed classed в коко
PolinaAksenova # 0 ⇈
bormand # 0 ⇈
PolinaAksenova # 0 ⇈
JloJle4Ka # 0
Давайте угадывать кто и как оскорбился на слово «Wheel».
bormand # 0 ⇈
[email protected] # 0 ⇈
booratihno # 0
Напоминает дешевые SEO тексты:
"Как покрасить стену?
Безусловно, каждому из нас рано или поздно приходится сталкиваться с вопросом: как покрасить стену?
Чтобы ответит на такой важный вопрос, как покрасить стену, предлагается прочитать вот эту статью, которая кстати так и накзывается: как покрасить стену"
booratihno # 0
petuh.setIq(-1).setName("dzhavist")
bormand # 0 ⇈
booratihno # 0 ⇈
guest # 0
bormand # 0 ⇈
JloJle4Ka # 0 ⇈
booratihno # 0 ⇈
между строками
employee->age = 99;
и
employee->salary = 100;
может быть куча кода!
JloJle4Ka # 0 ⇈
Типа
employee->salary = 25;
return;
?
guest # 0 ⇈
любая логика
bormand # 0 ⇈
JloJle4Ka # 0 ⇈
bormand # 0 ⇈
JloJle4Ka # 0 ⇈
Например:
r = request.addDetail("koko")
if (len == 1):
. . . . r.addDetail("ololo").fire()
else:
. . . . r.removeDetail("defolt").addCode(200).fi re()
bormand # 0 ⇈
JloJle4Ka # 0 ⇈
bormand # 0 ⇈
Да не, вот например какой-нибудь построитель запросов -- хороший, годный пример билдера.
Я пишу что-то в духе query.where(employee.name, "bormand").all() и мне пофиг, как билдер это будет переводить на конкретный диалект "SQL" (или даже "NoSQL").
Вот оно, то самое разделение между "что построить" и "как построить".
[email protected] # 0 ⇈
JloJle4Ka # 0 ⇈
DypHuu_niBEHb # 0 ⇈
JloJle4Ka # 0 ⇈
JloJle4Ka # 0 ⇈
bormand # 0 ⇈
На собеседованиях уже никто не спрашивает?
DypHuu_niBEHb # 0 ⇈
Но перед собеседами я обычно тренировал алгоритмы, их сложнее вспомнить, чем паттрены. Правда все равно ничего слоднее qsort и binary search на обычных работах не спрашивают
DypHuu_niBEHb # 0 ⇈
Но перед собеседами я обычно тренировал алгоритмы, их сложнее вспомнить, чем паттрены. Правда все равно ничего слоднее qsort и binary search на обычных работах не спрашивают
JloJle4Ka # 0 ⇈
DypHuu_niBEHb # 0 ⇈
Мое представление о дизайне примерно на уровне вот
gologub # 0 ⇈
gologub # 0 ⇈
bormand # 0 ⇈
Напишешь с первого раза, нигде не залетев на единичку и не соснув UB'ца?
DypHuu_niBEHb # 0 ⇈
Но не всегда просят писать: иногда просто нужно рассказать какие есть виды поиска, какие у них требования к данным, и какие большие О
JloJle4Ka # 0 ⇈
DypHuu_niBEHb # 0 ⇈
оно, кстати, зависит от сортированности говна изначально
JloJle4Ka # 0 ⇈
DypHuu_niBEHb # 0 ⇈
это худшее же. Его можно шафлнуть, чтобы такого говна не получить вроде (если не путаю)
JloJle4Ka # 0 ⇈
DypHuu_niBEHb # 0 ⇈
А про сортировку слиянием помнишь?
JloJle4Ka # 0 ⇈
DypHuu_niBEHb # 0 ⇈
В частности в джаве для примитивов ку, а для объектов был merge, но теперь там есть еще TimSort.
JloJle4Ka # 0 ⇈
Fike # 0 ⇈
[email protected] # 0 ⇈
JloJle4Ka # 0 ⇈
[email protected] # 0 ⇈
JloJle4Ka # 0 ⇈
PolinaAksenova # 0 ⇈
DypHuu_niBEHb # 0 ⇈
как эта хрень работает?
там как-то оператор == перегружен и чото такое возвращает?
PolinaAksenova # 0 ⇈
Да.
PolinaAksenova # 0 ⇈
Да.
DypHuu_niBEHb # 0 ⇈
В джанге это более попидарски, типа
PolinaAksenova # 0 ⇈
DypHuu_niBEHb # 0 ⇈
Кстати, ты умеешь пользоваться гибридными атрибутами в SQLAlchemy?
Это, имхо, самая киллер фича по сравнению с джангой
DypHuu_niBEHb # 0 ⇈
Кстати, ты умеешь пользоваться гибридными атрибутами в SQLAlchemy?
Это, имхо, самая киллер фича по сравнению с джангой
PolinaAksenova # 0 ⇈
DypHuu_niBEHb # 0 ⇈
если у тебя таких полей 22, то ты будешь 22 поля копипастить?
bormand # 0 ⇈
DypHuu_niBEHb # 0 ⇈
В примере с джавой -- паста. Правда это паста в ОДНОМ месте, а не во всех местах использования.
Алсо, см пример емейлпротектда с передачей билдера
bormand # 0 ⇈
DypHuu_niBEHb # 0 ⇈
Вот если бы там в структуре были какие-то методы, то да: без отдельного билдера бы не получилось, пушо пока билд не закончен объект не консистентен, и методы вызвать нельзя
DypHuu_niBEHb # 0
https://twitter.com/Jetskigrizzly/status/1382712270677942276
bootcamp_dropout # 0 ⇈
guest # 0 ⇈
bootcamp_dropout # 0 ⇈
guest # 0 ⇈
bootcamp_dropout # 0 ⇈
на практике получение произвольного кол-ва данных из прошлого обсера звучит сомнительно
MAKAKA # 0 ⇈
Правда конечно нужно гарантировать, что он подключится, иначе там буфер раздуется
Хотя.. он же навсегда закеширует ВСЕ данные?
bootcamp_dropout # 0 ⇈
Но чтобы нужно было хранить стейт обсервера между подключениями не припомню, разве что для расширения хрома где хуй знает когда что на страницу подгрузится
DypHuu_niBEHb # 0
Steve_Brown # 0 ⇈
guest # 0
https://caizcoin.com/
JloJle4Ka # 0 ⇈
CkpunmoBbIu_nemyx # 0
PolinaAksenova # 0
Можня было ня писать лишний конструктор, а проставить default-аргументы (Котлин бы сам сгенерировал отдельный Car(), кстати), но оригинал ня мог принимать ня все параметры, так что и мы ня будем.
В оригиняле, кстати, автор так вдохновился крутым "Builder Design Pattern" в toString(), что забыл поставить закрывающую квадратную скобку: видимо, от количества бойлерплейта, которого ему пришлось написать, мозг нямножко разжижился.
MAKAKA # 0 ⇈
Не хотел бы иметь возможность вызывать его методы
PolinaAksenova # 0 ⇈
Но да, без nullable этот класс в Котлине будет ещё няшнее.
MAKAKA # 0 ⇈
А на TS сделать (как и на крестах)
JloJle4Ka # 0 ⇈