Легаси никто не отменял. Есть проекты, в которых одни и те же технологии сохраняются десятками лет. Но новые проекты обычно используют то, чего 5 лет назад просто не существовало.
К сожалению когда в программировании возникает какой-то тренд, то все начинают эту трендовую концепцию пихать по делу и без.
Эта участь не обошла и паттерны. Поэтому части паттерны применяются не для решения конкретных задач и\или проблем, а просто для самовыражения программиста. Это видно даже по статьям на Хабре.
Я думаю к каждому применению паттрена надо задавать вопрос (возможно себе) "какую проблему он решает?", без внятного ответа паттерн скорее всего не нужен.
В программировании, конечно, денег больше, чем у учителей и врачей, но, как и врачам, надо постоянно учиться. Последние 20 лет (может и больше, но у меня нет столько опыта) в программировании тренд меняется каждые два года, а каждые 5 лет происходит полное обновление инструментария. Есть конечно набор "базовых" технологий, которые не меняются давно, но на них одних далеко не уедешь. При этом, в отличие от врачей, очень узкая специализация в программировании не приветствуется.
Поэтому если хочешь в ИТ, то будь готов постоянно что-то изучать. Это кроме стандартного 8-часового рабочего дня.
И как мне кажется статей на эту тему даже на хабре миллион.
А что вы хотели? Большинство программистов обучались этой профессии в Вузе, это 2-3 предмета каждый семестр в объеме около 40-60 каждый, лабы и курсовые, и так на протяжении 4-5 лет. И то выпускники ВУЗов обычно обладают недостаточными знаниями и навыками программирования, если самостоятельно не изучали технологии.
Я помню времена, когда джунами брали программистов, знающих минимум два языка и разбирающихся в БД.
А потом кто-то придумал, что можно стать программистом, изучив теоретический материал в объеме одной книжки и сделав две лабы. Увы, нельзя.
Имхо курсы переоценены. Они могут дать навык создавать todo list на реакте, но этот навык не обобщается на любые приложения.
Базовые навыки создания программ на js, понимание механик и особенностей языка, навык использования стандартной библиотеки и объектной модели браузера гораздо полезнее. Конечно такое обучение займет больше времени и вряд ли получится запилить проект на гитхабе в конце, но на практике будет гораздо полезнее.
DTO делать там, где можно без него, это антипаттерн. Прямое увеличение объема, связности и снижение mantainability index. Вы на ровном месте сделали код хуже, а преимущества крайне сомнительны.
рано или поздно люди начнут обращаться к внутрянке мойЗаказ.элементы[0]
А чего в этом плохого? И кто помешает также обращаться к dto?
Но это опять половина беды. Вводя dto между domain и persistence вы больше не можете использовать механизм запросов, предоставляемых orm.
То есть мало того, что код стал хуже, он ещё стал значительно медленнее.
Сори, но такой подход нежизнеспособен настолько что нет смысла дальше обсуждать. Ну или вы просто пример кода приведете, который работает и не абсурден.
Потому что я вижу сразу кучу проблем со скрытым состоянием объекта, которые не оправдываются вообще ничем.
Его нельзя сохранить в базу с помощью EF. Чтобы можно было сохранить нужно как минимум read-only свойство
У вас получается логика основанная на исключениях. Если единственный способ узнать что действие выполнить нельзя - вызвать Объект.Действие() , то вы никак не сможете скрыть\деактивировать элементы управления в UI. Даже try-pattern не поможет.
Вы не сможете логику действия вынести в отдельный класс.
В целом если вытащить наружу для чтения состояние объекта, то это никак не повредит его инкапсуляции, но поможет сделать остальной код лучше.
Да, но это не имеет значения. Действие с Объектом подчиняется той же логике что и правила. Чем сложнее действие, тем хороших способов поместить его в объект.
Имеет ли валидатор и сервисы доступ к внутреннему устройству объекта?
К внутреннему - нет. Использует тот же публичный интерфейс, который используется например для вывода списка объектов на экран. В варианте Объект.Действие() при достаточно сложном действии оно будет перенесено в сервис и будет иметь такой же доступ к объекту, как и Правило, написанное вне Объекта.
Правильно ли я понимаю, что вы топите за анемичную модель?
Я топлю за то, чтобы писать меньше, а работало лучше.
Но давайте пример проще: линейный односвязный список. Казалось бы никаких циклических ссылок. Но все равно на расте куча приседаний с борроучекером, а на python\java\C# проблем нет.
Экскаватор это не объект данных, а сервис, у которого нет наблюдаемого состояния. Так что нет семантической разницы между Копать(Эксковатор, Земля) и Эксковатор.Копать(Земля), но второй вариант лучше тестируется и имеет выше discoverability.
ООП для данной задачи в том, что Экскаватор это объект со своей структурой, декомпозицией. Земля это объект предметной области с Identity. Это означает что нельзя передать в метод невалидный ЗемляИД и, соответственно, не надо внутри метода Копать устраивать дополнительные проверки.
Он не может оплачиваемую работу найти?
А если вместо pub\sub скажет что это Observer? Или скажет что надо использовать список коллбеков или events?
Смотря что вы называете базой. Из всего что я учил в универе 15 лет назад на сегодня не устарели только теория БД и sql-92, а также частично HTTP.
Легаси никто не отменял. Есть проекты, в которых одни и те же технологии сохраняются десятками лет. Но новые проекты обычно используют то, чего 5 лет назад просто не существовало.
К сожалению когда в программировании возникает какой-то тренд, то все начинают эту трендовую концепцию пихать по делу и без.
Эта участь не обошла и паттерны. Поэтому части паттерны применяются не для решения конкретных задач и\или проблем, а просто для самовыражения программиста. Это видно даже по статьям на Хабре.
Я думаю к каждому применению паттрена надо задавать вопрос (возможно себе) "какую проблему он решает?", без внятного ответа паттерн скорее всего не нужен.
Кстати о правильном применении паттренов есть книга Дж.Криевски "Refactoring to Patterns". Без нее изучение GoF может нанести вред.
В программировании, конечно, денег больше, чем у учителей и врачей, но, как и врачам, надо постоянно учиться. Последние 20 лет (может и больше, но у меня нет столько опыта) в программировании тренд меняется каждые два года, а каждые 5 лет происходит полное обновление инструментария. Есть конечно набор "базовых" технологий, которые не меняются давно, но на них одних далеко не уедешь. При этом, в отличие от врачей, очень узкая специализация в программировании не приветствуется.
Поэтому если хочешь в ИТ, то будь готов постоянно что-то изучать. Это кроме стандартного 8-часового рабочего дня.
И как мне кажется статей на эту тему даже на хабре миллион.
Если ты можешь много чего решить, то реши задачи на leetcode ;)
Сейчас не спрашивают?
А цитируете зачем-то коммент про джунов.
Ну вы же знали на что идете или нет? Как вообще вы решили пойти в программирование?
А что вы хотели? Большинство программистов обучались этой профессии в Вузе, это 2-3 предмета каждый семестр в объеме около 40-60 каждый, лабы и курсовые, и так на протяжении 4-5 лет. И то выпускники ВУЗов обычно обладают недостаточными знаниями и навыками программирования, если самостоятельно не изучали технологии.
Я помню времена, когда джунами брали программистов, знающих минимум два языка и разбирающихся в БД.
А потом кто-то придумал, что можно стать программистом, изучив теоретический материал в объеме одной книжки и сделав две лабы. Увы, нельзя.
Разве на jquery кто-то сейчас пишет? Ну кроме вас.
В реакте он же совсем не нужен.
дайте ссылку на хорошие курсы чтоли
Имхо курсы переоценены. Они могут дать навык создавать todo list на реакте, но этот навык не обобщается на любые приложения.
Базовые навыки создания программ на js, понимание механик и особенностей языка, навык использования стандартной библиотеки и объектной модели браузера гораздо полезнее. Конечно такое обучение займет больше времени и вряд ли получится запилить проект на гитхабе в конце, но на практике будет гораздо полезнее.
Так и не понял при чем тут структура 1с, если все преимущества происходят только из визуальных дизайнеров.
Вот пример на питоне (в конце статьи) https://www.tutorialspoint.com/python_data_structure/python_linked_lists.htm
На расте https://rust-unofficial.github.io/too-many-lists/second-final.html
Даже если отбросить Iter, то в расте сильно больше операторов
DTO делать там, где можно без него, это антипаттерн. Прямое увеличение объема, связности и снижение mantainability index. Вы на ровном месте сделали код хуже, а преимущества крайне сомнительны.
А чего в этом плохого? И кто помешает также обращаться к dto?
Но это опять половина беды. Вводя dto между domain и persistence вы больше не можете использовать механизм запросов, предоставляемых orm.
То есть мало того, что код стал хуже, он ещё стал значительно медленнее.
Сори, но такой подход нежизнеспособен настолько что нет смысла дальше обсуждать. Ну или вы просто пример кода приведете, который работает и не абсурден.
Синглтон без состояния это же просто набор статических функций, не?
Сможете привести реалистичный рабочий пример?
Потому что я вижу сразу кучу проблем со скрытым состоянием объекта, которые не оправдываются вообще ничем.
Его нельзя сохранить в базу с помощью EF. Чтобы можно было сохранить нужно как минимум read-only свойство
У вас получается логика основанная на исключениях. Если единственный способ узнать что действие выполнить нельзя - вызвать
Объект.Действие(), то вы никак не сможете скрыть\деактивировать элементы управления в UI. Даже try-pattern не поможет.Вы не сможете логику действия вынести в отдельный класс.
В целом если вытащить наружу для чтения состояние объекта, то это никак не повредит его инкапсуляции, но поможет сделать остальной код лучше.
Да, но это не имеет значения. Действие с Объектом подчиняется той же логике что и правила. Чем сложнее действие, тем хороших способов поместить его в объект.
К внутреннему - нет. Использует тот же публичный интерфейс, который используется например для вывода списка объектов на экран. В варианте
Объект.Действие()при достаточно сложном действии оно будет перенесено в сервис и будет иметь такой же доступ к объекту, как иПравило, написанное внеОбъекта.Я топлю за то, чтобы писать меньше, а работало лучше.
Вы сейчас описали любую нетривиальную программу.
Но давайте пример проще: линейный односвязный список. Казалось бы никаких циклических ссылок. Но все равно на расте куча приседаний с борроучекером, а на python\java\C# проблем нет.
Экскаватор это не объект данных, а сервис, у которого нет наблюдаемого состояния. Так что нет семантической разницы между
Копать(Эксковатор, Земля)иЭксковатор.Копать(Земля), но второй вариант лучше тестируется и имеет выше discoverability.ООП для данной задачи в том, что Экскаватор это объект со своей структурой, декомпозицией. Земля это объект предметной области с Identity. Это означает что нельзя передать в метод невалидный ЗемляИД и, соответственно, не надо внутри метода Копать устраивать дополнительные проверки.