Сообщение Re[8]: Domain-Driven-Design и DataGridView не совместимы? от 02.10.2023 12:31
Изменено 02.10.2023 12:36 Alekzander
Re[8]: Domain-Driven-Design и DataGridView не совместимы?
Здравствуйте, gandjustas, Вы писали:
G>Недавно переводит статьи Липперта на эту тему https://habr.com/ru/articles/710748/
G>Он не такой авторитет как фаулер с эвансами, толстых книг, которые читали все программисты не писал, но разбирается в архитектуре не хуже их вместе взятых.
Я, наконец, прочитал эту длинную статью. Не то, чтобы я медленно читал, а просто ещё приходится отвлекаться на всякие глупости (типа работы). Плюс тебе в карму, а плюс за перевод самой статьи не могу поставить (она истекла).
Это отличная иллюстрация к тому, что я написал выше.
Дураку понятно, что в реальном проекте надо писать админку с карточками игроков и оружия, а констрейнты — кто кого может иметь и куда — считывать из файлов, приготовленных гейм-дизайнерами (как и всё остальное).
Откуда же берётся такое г-но, описанное Липпертом?
Да вот оттуда и берётся. Когда, допустим, я говорю: в хорошем коде отражается предметная область. А, допустим, ты говоришь: это бла-бла-бла, гони конкретику. Допустим, я не понимаю, что не каждый фундаментальный принцип — такой, как доменной дизайн или второе начало термодинамики — можно свести к набору более простых правил (это свойство называется "эмерджентность"), и чтобы хоть что-то тебе ответить, говорю: выпиши в блокнот игровые понятия и проследи, чтобы каждому соответствовал хоть какой-то сишарповский класс. И вот результат.
К счастью, это был просто пример. А реальный я скажу тебе, что нет таких приёмов, которые можно применять не думая, чтобы обеспечить выполнение этого принципа (почему — я уже объяснил: это запрет, налагаемый законами природы на творческие процессы). А если делать это думая, то указанный принцип должен быть воплощён в форме класса, который считывает приготовленные карточки. Потому, что именно так НА САМОМ ДЕЛЕ устроена предметная область. И несмотря на высокоуровневость этого принципа, смысл в нём принципе есть. Например, если ты напишешь код констрейнта на оружие в отдельном хелпере — ты его нарушишь.
G>Недавно переводит статьи Липперта на эту тему https://habr.com/ru/articles/710748/
G>Он не такой авторитет как фаулер с эвансами, толстых книг, которые читали все программисты не писал, но разбирается в архитектуре не хуже их вместе взятых.
Я, наконец, прочитал эту длинную статью. Не то, чтобы я медленно читал, а просто ещё приходится отвлекаться на всякие глупости (типа работы). Плюс тебе в карму, а плюс за перевод самой статьи не могу поставить (она истекла).
Это отличная иллюстрация к тому, что я написал выше.
Дураку понятно, что в реальном проекте надо писать админку с карточками игроков и оружия, а констрейнты — кто кого может иметь и куда — считывать из файлов, приготовленных гейм-дизайнерами (как и всё остальное).
Откуда же берётся такое г-но, описанное Липпертом?
Да вот оттуда и берётся. Когда, допустим, я говорю: в хорошем коде отражается предметная область. А, допустим, ты говоришь: это бла-бла-бла, гони конкретику. Допустим, я не понимаю, что не каждый фундаментальный принцип — такой, как доменной дизайн или второе начало термодинамики — можно свести к набору более простых правил (это свойство называется "эмерджентность"), и чтобы хоть что-то тебе ответить, говорю: выпиши в блокнот игровые понятия и проследи, чтобы каждому соответствовал хоть какой-то сишарповский класс. И вот результат.
К счастью, это был просто пример. А реальный я скажу тебе, что нет таких приёмов, которые можно применять не думая, чтобы обеспечить выполнение этого принципа (почему — я уже объяснил: это запрет, налагаемый законами природы на творческие процессы). А если делать это думая, то указанный принцип должен быть воплощён в форме класса, который считывает приготовленные карточки. Потому, что именно так НА САМОМ ДЕЛЕ устроена предметная область. И несмотря на высокоуровневость этого принципа, смысл в нём принципе есть. Например, если ты напишешь код констрейнта на оружие в отдельном хелпере — ты его нарушишь.
Re[8]: Domain-Driven-Design и DataGridView не совместимы?
Здравствуйте, gandjustas, Вы писали:
G>Недавно переводит статьи Липперта на эту тему https://habr.com/ru/articles/710748/
G>Он не такой авторитет как фаулер с эвансами, толстых книг, которые читали все программисты не писал, но разбирается в архитектуре не хуже их вместе взятых.
Я, наконец, прочитал эту длинную статью. Не то, чтобы я медленно читал, а просто ещё приходится отвлекаться на всякие глупости (типа работы). Плюс тебе в карму, а плюс за перевод самой статьи не могу поставить (она истекла).
Это отличная иллюстрация к тому, что я написал выше.
Дураку понятно, что в реальном проекте надо писать админку с карточками игроков и оружия, а констрейнты — кто кого может иметь и куда — считывать из файлов, приготовленных гейм-дизайнерами (как и всё остальное).
Откуда же берётся такое г-но, описанное Липпертом?
Да вот оттуда и берётся. Когда, допустим, я говорю: в хорошем коде отражается предметная область. А, допустим, ты говоришь: это бла-бла-бла, гони конкретику. Допустим, я не понимаю, что не каждый фундаментальный принцип — такой, как доменной дизайн или второе начало термодинамики — можно свести к набору более простых правил (это свойство называется "эмерджентность"), и чтобы хоть что-то тебе ответить, говорю: выпиши в блокнот игровые понятия и проследи, чтобы каждому соответствовал хоть какой-то сишарповский класс. И вот результат.
К счастью, это был просто пример. А реальный я скажу тебе, что нет таких приёмов, которые можно применять не думая, чтобы обеспечить выполнение этого принципа (почему — я уже объяснил: это запрет, налагаемый законами природы на творческие процессы). А если делать это думая, то указанный принцип должен быть воплощён в форме класса, который считывает приготовленные карточки. Потому, что именно так НА САМОМ ДЕЛЕ устроена предметная область. И несмотря на высокоуровневость этого принципа, смысл в нём есть. Например, если ты напишешь код считывания констрейнтов на оружие в отдельном хелпере — ты его нарушишь.
G>Недавно переводит статьи Липперта на эту тему https://habr.com/ru/articles/710748/
G>Он не такой авторитет как фаулер с эвансами, толстых книг, которые читали все программисты не писал, но разбирается в архитектуре не хуже их вместе взятых.
Я, наконец, прочитал эту длинную статью. Не то, чтобы я медленно читал, а просто ещё приходится отвлекаться на всякие глупости (типа работы). Плюс тебе в карму, а плюс за перевод самой статьи не могу поставить (она истекла).
Это отличная иллюстрация к тому, что я написал выше.
Дураку понятно, что в реальном проекте надо писать админку с карточками игроков и оружия, а констрейнты — кто кого может иметь и куда — считывать из файлов, приготовленных гейм-дизайнерами (как и всё остальное).
Откуда же берётся такое г-но, описанное Липпертом?
Да вот оттуда и берётся. Когда, допустим, я говорю: в хорошем коде отражается предметная область. А, допустим, ты говоришь: это бла-бла-бла, гони конкретику. Допустим, я не понимаю, что не каждый фундаментальный принцип — такой, как доменной дизайн или второе начало термодинамики — можно свести к набору более простых правил (это свойство называется "эмерджентность"), и чтобы хоть что-то тебе ответить, говорю: выпиши в блокнот игровые понятия и проследи, чтобы каждому соответствовал хоть какой-то сишарповский класс. И вот результат.
К счастью, это был просто пример. А реальный я скажу тебе, что нет таких приёмов, которые можно применять не думая, чтобы обеспечить выполнение этого принципа (почему — я уже объяснил: это запрет, налагаемый законами природы на творческие процессы). А если делать это думая, то указанный принцип должен быть воплощён в форме класса, который считывает приготовленные карточки. Потому, что именно так НА САМОМ ДЕЛЕ устроена предметная область. И несмотря на высокоуровневость этого принципа, смысл в нём есть. Например, если ты напишешь код считывания констрейнтов на оружие в отдельном хелпере — ты его нарушишь.