Согласна, решение с передачей объекта в конструктор выглядит гораздо элегантнее и убирает всю эту рутину с this[var] = value. Прямо минимализм, который и читать приятнее, и писать быстрее.
Подход с передачей объекта в конструктор и автоматическим присваиванием свойств выглядит лаконично. Часто ли используете его на практике? Есть ли подводные камни?
Да, это действительно банальное перекрытие области видимости, но для новичков даже оно иногда выглядит как магия. А что для вас казалось необъяснимым чудом в коде?
Смею предположить, что каждого своя боль и магия на старте)))))
Ваш комментарий, возможно, показался немного снисходительным, как будто сказан с высоты опыта и насмешкой, но его можно было бы подать интереснее и полезнее, и я вижу в нём хороший потенциал для конструктивного обсуждения. Например, вы могли бы отметить, как в LibreOffice применены описанные в статье подходы. 😉
Ну или вы хотели лёгкую подачу от меня про LibreOffice? :)
Тогда вот она: представьте огромный офис, где у каждого отдела (Writer, Calc, Impress) свои задачи. Эти отделы общаются через общего курьера (SAL), а вся инфраструктура, от интернета до кофемашины (VCL), поддерживает их работу. Каждый слой делает своё дело, чтобы офис работал как единая система. Конечно, иногда курьер может застрять в лифте или кофе закончится в самый неподходящий момент, но в этом и есть сложность архитектуры!
Благодарю за такую интересную параллель! Может быть, моя статья действительно немного напоминает подобные классификации своим желанием упростить сложное. Но моя цель — не запутать, а наоборот, сделать архитектуры ПО понятными и даже немного увлекательными. Если получилось, то это уже успех! Я начинаю с самого начала, с того, с чего все мы когда-то начинали, чтобы помочь тем, кто только делает первые шаги в этой теме.
Согласна 🫣 в любом случае, поделитесь как станет яснее) будем считать, если нет продолжения, то и нет проблем, все тихо)
а вот действительно, если с именем бота натворили дел, то придут к владельцу - к вам
интересно конечно...
ждем продолжения, надеюсь позитивного
у вас какой план? Просто ждать?
Спасибо большое!
Согласна, с иллюстрациями было бы значительно нагляднее)
Но ведь следы передачи прав управления всё равно должны где-то оставаться, или я ошибаюсь?
«Лучший способ обокрасть банк — сначала стать его директором».
Может, он рассчитывает войти в доверие, а потом провернуть что-то действительно масштабное 0_о
У вас там случайно не коллекция суперредких юзернеймов? :D
Мне кажетс, что он решил разогреть доверие…)
Согласна, решение с передачей объекта в конструктор выглядит гораздо элегантнее и убирает всю эту рутину с
this[var] = value. Прямо минимализм, который и читать приятнее, и писать быстрее.Подход с передачей объекта в конструктор и автоматическим присваиванием свойств выглядит лаконично. Часто ли используете его на практике? Есть ли подводные камни?
Да, это действительно банальное перекрытие области видимости, но для новичков даже оно иногда выглядит как магия. А что для вас казалось необъяснимым чудом в коде?
Смею предположить, что каждого своя боль и магия на старте)))))
Каждому времени свои
this-испытания :DА для уменьшения объема логов можно использовать разные уровни логирования (например, info, warn, error), чтобы записывать только важные события.👀
Спасибо за дополнение! 👍🏼
интересная задумка!
Мне очень понравилась, особенно в предверии Нового года!)
Ваш комментарий, возможно, показался немного снисходительным, как будто сказан с высоты опыта и насмешкой, но его можно было бы подать интереснее и полезнее, и я вижу в нём хороший потенциал для конструктивного обсуждения. Например, вы могли бы отметить, как в LibreOffice применены описанные в статье подходы. 😉
Ну или вы хотели лёгкую подачу от меня про LibreOffice? :)
Тогда вот она: представьте огромный офис, где у каждого отдела (Writer, Calc, Impress) свои задачи. Эти отделы общаются через общего курьера (SAL), а вся инфраструктура, от интернета до кофемашины (VCL), поддерживает их работу. Каждый слой делает своё дело, чтобы офис работал как единая система. Конечно, иногда курьер может застрять в лифте или кофе закончится в самый неподходящий момент, но в этом и есть сложность архитектуры!
Спасибо за поддержку! Очень волнительно)
Благодарю за такую интересную параллель! Может быть, моя статья действительно немного напоминает подобные классификации своим желанием упростить сложное. Но моя цель — не запутать, а наоборот, сделать архитектуры ПО понятными и даже немного увлекательными. Если получилось, то это уже успех! Я начинаю с самого начала, с того, с чего все мы когда-то начинали, чтобы помочь тем, кто только делает первые шаги в этой теме.