Ответы идут в аудио формате, вот ответ на один из последних вопросов (для примера).
На платформе всегда можно получить ответ. Это бесплатно, ответ даю по мере времени.
Для тех кто на платных подписках можно слушать ответы другим участникам в "Вопрос/ответ" вкладка "Все вопросы".

Давайте поговорим про приватные и публичные свойства в классах. Существует много разных претензий к публичным свойствам, в этом видео поговорим, про ограничения на значения свойств.
https://youtu.be/0lQFrD7kq3k

Приятно видеть как развиваются подписчики, Роман - один из моих старых зрителей, помню года два назад такую дичь писал. А теперь замечает многие моменты, которые другие не замечают.

За годы проектирования я понял только одно - всегда можно сказать почему то или иное решение плохое, но это нисколько не приблизит тебя к понимаю того что нужно сделать, чтобы решение (я больше про архитектуру говорю) стало хорошим.
Обычно устраняя одни недостатки, получаешь другие.

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

Можно ли бросать исключение из конструктора?
Коротко: Да
Чуть более длинно:
https://isocpp.org/wiki/faq/exceptions#ctors-can-throw

Обычно конструктор вызывает страхи потому что нет уверенности в том как он работает. Вроде как особый метод, который находится на границе когда объект вроде как создан, а вроде как и нет (не инициализирован). Отсюда мысль "мало ли что". В свой практике я каких-то диких проблем с бросанием исключений в конструкторе не встречал.

Кстати, да. Но мне такой терминологией пользоваться неудобно. Я не знаю кто изначально придумал отделять поля (field) от свойства (property), думаю это впервые появилось в С#. Но проблема вот в чем: поле - это техническая реализация свойства, т.е. поле - это "переменная" класса, а свойство - это геттер или сеттер для этого поля. Запутались?

Проблем в том, что эта терминология еще хуже проявляет себя когда вы работаете с заказчиком (вспоминаем про DDD и Ubiquitous Language) у вас есть объекты предметной области, и для их описания вполне достаточно свойств и методов.
Более того, если сказать бизнес аналитику, что кроме свойств в обсуждаемом объекте есть еще и поля, то он просто этого не поймет.

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

Мне кажется такие детали несущественны и только запутывают.

Есть общее для всех наук определение "свойства" и только в информатике из него умудрились сделать не пойми что.
Тут наверняка и проблемы перевода, и то что информатика отдельно, а программисты отдельно. Нет системного подхода в программировании, все стихийно

TGIF а значит очередной конкурс с розыгрышом подписки уровня "STREAM".
Тема свободная, публикуйте свои авторские фото в этой теме и то фото, которое соберёт больше реакций, определит победителя.
Желательно убликовать что-то свящангое с лайфстайлом программиста.

Признаки того, что у программиста все хорошо с абстрактным мышлением:
1. Умение проектировать "на бумаге", не используя синтаксис ЯП
2. Присутствие интерфейсов и абстрактных классов в коде (dip)
3. Умение построить мат. модель или модель предметной области
4. Умение разбивать задачу на уровни абстракции
5. Понимание архитектурных границ и разделения обязанностей.

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

На soer.pro опубликовал 24ое архитектурное видео (архитектурные стримы) по проектированию RESTful приложений.

Согласны ли вы с утверждением, что принцип инверсии зависимостей (DIP) в JavaScript не применим? Палец вверх - да, остальное нет.
Если считаете, что применим, то в комментах интересно услышать как это должно выглядеть?

Вот еще один вопрос, который показывает понимание DI и IoC. Вопрос звучит так "Всегда ли при использовании (dependency injection) DI осуществляется инверсия управления (IoC)"? Палец вверх - да, остальное - нет.
Объяснение своего понимания можно дать в комментариях.

Я не зря спросил про DI и IoC. Это пример того как первоначально прозрачная и понятная концепция "замусорилась". Появился IoC 1,2,3 типа и DI (что тоже самое).
Хотя по смыслу DI куда ближе к обычному полиморфизму, а не IoC. Но концепция "управления" сложная, поди разберись кто там кем управляет и у кого прямой поток, а у кого инвертированный. Практика, как всегда, не требует таких сложных "измышлений".

Источник: https://web.archive.org/web/20040202120126/http://www.betaversion.org/~stefano/linotype/news/38/