В качестве прикладного смысла могу предложить возвращать уже существующий экземпляр текущего класса, если входные параметры эквивалентны уже созданному и закешированному экземпляру этого класса.
Для этого уже существуют паттерны, не нарушающие ООП - статические фабричные методы или отдельный FlyweightFactory.
Еще в голову приходит идея возвращать наследников текущего класса на основе передаваемых параметров. Да, это немножко "не по правилам ооп", но мне кажется довольно удобным решением, когда в базовый класс ты передаешь параметры, а он уже сам решает, что создать.
Да в принципе конструктор может вернуть все что угодно, в том числе и объект другого класса. Но, имхо, это пахнет говнокодом.
class MyClass1 {
name='MyClass1'
}
class MyClass2 {
constructor() {
return new MyClass1()
}
}
const obj = new MyClass2();
console.log(obj)
MyClass1 {name: 'MyClass1'}
console.log(obj instanceof MyClass1);
true
console.log(obj instanceof MyClass2);
false
Если говорить про то что "под капотом" реализации классов JS - то да.
Но если на уровне TypeScript или ES6 - то там есть явно выделенные классы, и экземпляр объекта можно получить созданием из класса, как в языках с "правильным" ООП. И если нужно получить два объекта с одинаковым классом, мы берем и создаем два объекта. Опять же оговорюсь, на этому уровне абстракции нам пофигу что это синтаксический сахар пад прототипным наследованием.
const obj1 = new MyClass();
...
const obj2 = new MyClass();
А вот зачем нам может понадобиться создавать новый объект из существующего объекта? Зачем из почти настоящего ООП нам обратно нырять в не совсем настоящую реализацию?
Я могу представить только какой-то экзотиеческий сценарий, когда мы работаем с какой-то легаси библиотекой, куда нам нужно пробросить объект конкретного класса, но нам по какой-то причине недоступен конструктор таких объектов (не экпортирован из либы?), и мы объект нашего класса заставляем прикидываться другим классом. Но это какой-то фантастический на мой взгляд сценарий.
"Рекурсивные конструторы и наследование от экземпляров" звучит как инструмент или решение, но для каких прикладных задач? Для какой фичи? Можете привести пример "из жизни" когда это требуется?
"Наследование от экземпляра" уже звучит несколько жутковато, и кажется результатом неудачной архитектуры.
А что при этом произойдёт с foreign keys и views, которые ссылаются на оптимизируемую таблицу? А если на эту таблицу триггеры уже навешаны? Что с партицированием?
И ещё стоит не забывать про заморозку картежей, копируя данные в новую таблицу мы по факту обнуляем заморозку.
Вообще некорректная трактовка Agile. К нужному результату вы можете не прийти как с классическим подходом, так и с Agile подходом. Но с Agile подходом вы это поймёте раньше, и перестаните тратить ресурсы. Если приготовили Agile правильно. А если не правильно - то наговнякаете как и при любом другом подходе.
Справедливое название статьи "За все хорошее против всего плохого". К сожалению, примерами, как было обещано, даже и не пахнет. Автор, попробуй другой промпт.
Лет 15 назад как подобную историю рассказывали на Agile тренингах. Не пытаясь выдать за реальную, а скорее как байку, с моралью что не всегда можно чётко измерить эффективность конкретного человека, нужно смотреть шире на impact в разрезе команды/компании.
"Мораль" - это же не что-то абсолютное. Не обязательно должна развиваться в направлении гуманных концепций. Да и забота о животном мире вполне может быть и в рамках прагматичного видения выгоды для своего вида. В конце-концов даже самые "моральные" без особых слез уничтожают комаров, тараканов и крыс.
Да и "развитие", с точки зрения природы, не всегда усложнение, иногда это наоборот упрощение. Или по крайней мере "заморозка". По мнению учёных, те же акулы мало изменились за миллионы лет.
Мы сейчас проецируем на искуственный интеллект нашу модель мышления. Что естественно - другой модели мы не знаем. И вообщем говоря небезосновательно делаем - он же учится на наших материалах, поэтому можем рассчитывать, что будет мыслить так же как мы. По крайней мере сначала. С другой стороны, даже в человеческой популяции рождаются индивиды с очень отличающимися моральными принципами - психопаты и серийные убийцы.
Из статьи не понятно зачем это нужно, какие проблемы решает, какие кейсы использования. Можно, конечно, пойти изучить первоисточник, но хотелось бы получить хоть какую-то ценность от статьи на Хабре.
Забыли про английский язык написать. Удобно использовать для чтения документации. А ещё буквы и цифры есть, тоже полезные в работе штуки. Не говоря уже про командную строку. Но это наверное в следующем промпте, да?
Было бы здорово увидеть описание инструмента в форме кейсов. Пока что кажется что штука полезная, но как её начать использовать в своих проектах - не понятно.
Для этого уже существуют паттерны, не нарушающие ООП - статические фабричные методы или отдельный FlyweightFactory.
Да в принципе конструктор может вернуть все что угодно, в том числе и объект другого класса. Но, имхо, это пахнет говнокодом.
Если говорить про то что "под капотом" реализации классов JS - то да.
Но если на уровне TypeScript или ES6 - то там есть явно выделенные классы, и экземпляр объекта можно получить созданием из класса, как в языках с "правильным" ООП. И если нужно получить два объекта с одинаковым классом, мы берем и создаем два объекта. Опять же оговорюсь, на этому уровне абстракции нам пофигу что это синтаксический сахар пад прототипным наследованием.
А вот зачем нам может понадобиться создавать новый объект из существующего объекта? Зачем из почти настоящего ООП нам обратно нырять в не совсем настоящую реализацию?
Я могу представить только какой-то экзотиеческий сценарий, когда мы работаем с какой-то легаси библиотекой, куда нам нужно пробросить объект конкретного класса, но нам по какой-то причине недоступен конструктор таких объектов (не экпортирован из либы?), и мы объект нашего класса заставляем прикидываться другим классом. Но это какой-то фантастический на мой взгляд сценарий.
"Рекурсивные конструторы и наследование от экземпляров" звучит как инструмент или решение, но для каких прикладных задач? Для какой фичи? Можете привести пример "из жизни" когда это требуется?
"Наследование от экземпляра" уже звучит несколько жутковато, и кажется результатом неудачной архитектуры.
Я, возможно, чего-то не понимаю.
Очень ждал что будет раскрыт какой-то прикладной смысл этого упражнении. Но так и не нашёл :(
А ещё есть is distinct from, которое нормально работает с null
В статье ссылка битая https://github.com/mermaid-js/mermaid%23readme
А что при этом произойдёт с foreign keys и views, которые ссылаются на оптимизируемую таблицу? А если на эту таблицу триггеры уже навешаны? Что с партицированием?
И ещё стоит не забывать про заморозку картежей, копируя данные в новую таблицу мы по факту обнуляем заморозку.
Вообще некорректная трактовка Agile. К нужному результату вы можете не прийти как с классическим подходом, так и с Agile подходом. Но с Agile подходом вы это поймёте раньше, и перестаните тратить ресурсы. Если приготовили Agile правильно. А если не правильно - то наговнякаете как и при любом другом подходе.
Справедливое название статьи "За все хорошее против всего плохого". К сожалению, примерами, как было обещано, даже и не пахнет. Автор, попробуй другой промпт.
А тут точно не опечатка?
из документации
Т.е. в данном случае мы получаем последнее значение speed в конце интервала. Максимальное значение мы получили бы просто через max(speed)
Лет 15 назад как подобную историю рассказывали на Agile тренингах. Не пытаясь выдать за реальную, а скорее как байку, с моралью что не всегда можно чётко измерить эффективность конкретного человека, нужно смотреть шире на impact в разрезе команды/компании.
"Мораль" - это же не что-то абсолютное. Не обязательно должна развиваться в направлении гуманных концепций. Да и забота о животном мире вполне может быть и в рамках прагматичного видения выгоды для своего вида. В конце-концов даже самые "моральные" без особых слез уничтожают комаров, тараканов и крыс.
Да и "развитие", с точки зрения природы, не всегда усложнение, иногда это наоборот упрощение. Или по крайней мере "заморозка". По мнению учёных, те же акулы мало изменились за миллионы лет.
Мы сейчас проецируем на искуственный интеллект нашу модель мышления. Что естественно - другой модели мы не знаем. И вообщем говоря небезосновательно делаем - он же учится на наших материалах, поэтому можем рассчитывать, что будет мыслить так же как мы. По крайней мере сначала. С другой стороны, даже в человеческой популяции рождаются индивиды с очень отличающимися моральными принципами - психопаты и серийные убийцы.
Заявленная тема про уход "в стартап" не раскрыта. Малый бизнес не равно стартап. И профиль "дизайн-студия" тоже не пахнет стартапом.
Жесть. Ждал практические кейсы использования LLM для Postgres. Получил статью про то комментарии сущностей. LLM и Postgres протянуты за уши.
Где тут поставить минус, что не тратить время на пустые статьи с кликбейтным заголовком?
Валидация и сериализация есть из коробки
https://docs.nestjs.com/techniques/validation
https://docs.nestjs.com/techniques/serialization
Под капотом class-validator и class-transformer
+ декораторы openapi
Из статьи не понятно зачем это нужно, какие проблемы решает, какие кейсы использования. Можно, конечно, пойти изучить первоисточник, но хотелось бы получить хоть какую-то ценность от статьи на Хабре.
Забыли про английский язык написать. Удобно использовать для чтения документации. А ещё буквы и цифры есть, тоже полезные в работе штуки. Не говоря уже про командную строку. Но это наверное в следующем промпте, да?
Как так-то? Он по гиперболе летел. Залетел-повернул-вылетел.
Было бы здорово увидеть описание инструмента в форме кейсов. Пока что кажется что штука полезная, но как её начать использовать в своих проектах - не понятно.
Если вы даете задачки из вашего бизнес-домена - отлично. Есть школьные головоломки - уже сомнительно.
Хотя, так можно попробовать проверить, что человек не просто зачитывет ответы aI