Сергей
@tac
Программист
Information
- Rating
- Does not participate
- Registered
- Activity
Specialization
Game Developer, Software Architect
Lead
C#
OOP
ASP.Net
MSSQL
Game Development
C++
Programming microcontrollers
Software development
WPF
Unity3d
Это конечно смело, на моем канале много еще чего смелого, например критика, да чего уж там, высмеивание, Принцип единой ответственности ... и ведь действительно, сейчас популярно молиться на эти глупые принципы и не думать своей головой ... Смелость тут только в том, что высказываются адекватные аргументы, а не то, что считается популярным у студентов ..
Да о чем тут с тобой дискутировать, уровень школьника ... грубость с моей стороны, да, нет её, просто не могу серьезно обсуждать с тем у кого шоры на глазах и недостаточное образование. Да, и хамить ты начал сам ...
Спасибо за перевод этой статьи, переписал на C#, буду использовать в своей игре, как симуляцию песчаной бури.
Начните от сюда (это все мои статьи, так или иначе связанные с MVC)
https://habr.com/ru/post/138461/ - Правильное использование паттерна «Мост» (Мост с двухсторонним движением) или MVC->«Бизнес-сущность — Визуализация — Контроллер»
https://habr.com/ru/post/219445/ - Где наша бизнес-логика для идеалиста?
https://habr.com/ru/post/668928/ - Как учат создавать игру вида TowerDefence — ошибки «новичков»
https://habr.com/ru/post/670884/ - Когда в Unity нужно MVC, как сделать Binding визуальных контроллов с методом
А затем, я думаю, вам будет полезно посмотреть и прилагающиеся видео, это в том числе - они вас погрузят глубже, чем статьи. Правда не факт, что у вас такая цель. Но для того, чтобы разобраться в теме - это лучше.
Наверно, если у вас нет, что конструктивно сказать - это уже показатель. Советую, лишь читать и слушать - независимо от формата, что говорят взрослые дяди, такие как я и не перечить старшим. Это не вам должно быть удобно, а мне ...
а проблема того, что хабр давно стал токсичным местом, увы, не моя ... но именно такие как вы делают в это большой вклад, но большая ответственность конечно на владельцах.
Вы упорствуете в своем невежестве. Хорошо. Вот вам просто мои статьи на этот же вопрос, когда вы под стол пешком ходили. https://habr.com/ru/post/138461/
https://habr.com/ru/post/670884/
https://www.youtube.com/watch?v=joEGQ_Lb14M
думаю вы там мало чего поймете, но это статьи когда и как нужно использовать MVC
это статья о том когда не нужно.
И еще есть видео, во что превращается код, когда такие как вы не понимают когда, нужно и когда не нужно
https://www.youtube.com/watch?v=QYNaaxkfH-Y&t=30s
upd. внезапно, прошел по первой ссылке и увидел, что еще и тогда, вы так и не понимали ничего о контроллерах, читая мои статьи на этот счет, думаю - это проф. не пригодность. Но теперь у вас есть больший выбор, с того времени я для таких написал и снял разные вариации, чтобы они хотя бы немного поняли бы границы применения MVC. Успехов!
Правилами не запрещено, но в формате статьи так подробно не получится донести, поэтому привыкайте. Будет интересовать действительно тема, а не промотать по диагонали - послушаете, а нет проходите мимо. Мало ли чего вы там хотите, у меня вот в таком формате, таймкоды дал.
А то, что тут неадекватно оценивают - так это не новость, хабратушканчиков давно знаю :)
Да, задача бизнес логики решать через какое UI работать в том или ином случае. И делает это вышестоящий в иерархии класс. Несмотря на ваши общие тезисы без примеров, я их могу привести. Например, класс Society в моем примере будет решать в зависимости от поведения игрока, показать ему информацию о персоне упрощенно, или подробно. Да, именно он настроит это вместо избыточного контроллера.
т.е. изменения все равно будут, разница лишь в том - где? Только вместо того, чтобы вводить избыточную сущность контроллера, изменения затронут просто вышестоящий в иерархии класс (модель верхнего уровня)
Или я не понял ваш комментарий, или вы лукавите. Расскажите мне как при изменении элемента UI в MVC ничего не меняется? Если вы добавляете отображение скажем Description.text , то как же не изменится биндинг, если такого свойства вообще раньше не было? А если переименовываете скажем Name в NamePerson - у вас действительно не изменится биндинг и он продолжит синхронизировать не существующие уже свойство Name?
Так какое изменение вы имели введу?
37 стр.
Ну, что же. Очевидное разъяснение про MVC в итоге не понравилось. Псевдо-учителя учат тому, что не знают сами для чего нужно, в итоге 10-кратный оверхед. Людей, которые это ценят меньше. Бред про коде стайл, да еще очевидно неверный - плюсуют. Здесь серьезно есть специалисты? Думаю, нет. За, сим, откланиваюсь, пока тут не появятся думающие люди, разбирающиеся хоть немного в профессии программиста, а фрики мне как то поднадоели.
Кто же все таки захочет задать вопрос или прокомментировать - прошу на мой канал.
Серьезно? Чтобы решить пустячковую задачу - потянем в свой код, какой то не нужный фреймворк? Вот поэтому я пишу свои статьи, тем кто не хочет излишнего кода в своих проектах.
Но давайте так, я уеду на 2 недели, а вы реализуйте биндинг на Zenject - вы же это предлагали? А я приеду почитаю, покритикую, сделаем win-win :) ?
Ох, пристыдил то как ... но единственной моей задачей было сбить спесь, и заставить не писать так безапелляционно, таким как вы ... Теперь, когда вы еще кому ни будь напишите про коде стайл, пишите именно так (сделаю вам win):
"вариант читается на мой взгляд гораздо легче. Я допускаю что в некоторых компаниях предпочитают так не делать ..."
Да, я в такой работаю ..
"Зачем два раза писать имя класса? Визуальный мусор " - это глупость в том месте тип не написан, во время рефакторинга необходимо многое править в зависимости от типа, наличие var - очень сильно замедляет рефакторинг, а тут я могу по праву сослаться на опыт :)
"Она не лишняя, её предназначение - удобочитаемость. "
у Фаулера почитайте про временную переменную - это признак кода с душком , а вы мне предложили её ввести. Отличие опытного программиста, это не подаваться на провокации :) И нет удобочитаемостью вы пожертвовали столько раз, что это уже не аргумент
Дальше откройте, книгу "Балена Ф. и Димауро Д. - Современная практика программирования на Microsoft Visual Basic и Visual C# - 2006"
Но это (Фаулер) входит в противоречие с правилом 12.25 - но в моем случае и не было, как минимум длиной вложенности
"Это наверное самое субъективное из всего списка. Вариант с явным сравнением с false сильнее визуально нагружает, на мой взгляд. "
Как не странно, но правило 18.9 за ваш подход. Но, в случае конкретно этого случая - там не простое сравнение с переменной в моем случае (вы то ввели бесполезную), поэтому, тут мне надо писать , имхо, знак ! плохо виден в отличие от единообразного сравнения с == flase / == true (да, и слова "сильнее визуально нагружает" - надо воспринимать так, что для этого то я это и делал)
О return - Правило 14.16 Единственная точка выхода ... тут вам надо просто подучить мат. часть
Так же у Фаулера читайте про декомпозицию и консалидацию условных выражений, для вас будет полезно, не будете делать больше такие ошибки, но т.к. вы не ответили на это изначально, будем думать что поняли свои ошибки ...
И нет у нас не идеологические разногласия, а разногласия с человеком, который не нюхав пороха решил учить других. Думаете, если бы вы написали бы сразу со всеми этими "я думаю, имхо, для меня, для места, где я работал" - я бы так отреагировал? Моя реакция вызвана, исключительно, вашей без аппеляционностью в первом сообщениии.
И да я не на Марсе, вижу, что вас плюсуют - но вы особо не обольщайтесь ... я отношу это к деградации нашей профессии, иначе бы не отвечал вам ... Буду писать пока мне дадут тут писать ... но не прогибаясь под популярные ,не глубокие, и по сути ошибочные тенденции ...
Да, еще мини урок для любителей схлопывать условия, типа
if (Related != null && !IsDoneBinding(behaviorName))
не делайте так никогда. Код должен быть удобен для рефакторинга, условия это одно из главного, что часто меняется. Понятно когда условие вложено в условие это аналог && но во-первых, это становится не так при наличии else. А во-вторых, и в главных, условия должны быть атомарными, относится к одного рода проверке. Здесь они о разном Related != null - это есть ли партнер для связывания, а IsDoneBinding - был ли биндинг сделан.
Поэтому при малейшем изменении, усложнении задачи все это поплывет, тому кто будет делать рефакторинг придётся разбирать ваше схлопывание. А это и есть критерий нужности таких изменений.
Что собственно и было в моем коде, я писал, что он сложнее, и я его упрощал ...
Ну, и раз зашла такая тема. Некоторые наблюдения.
2 курс. Без разницы как писать код, лишь бы работал ...
5 курс. Начинаешь верить в какую-то идеализацию. Вырабатываешь свои взгляды на стиль ...
1-5 года работы. Смотря как повезет, если такие же молодые как ты - то вы начинаете заниматься ерундой - стандартизировать стиль в компании. Если нет, не понимаешь почему другие мамонты не хотят менять свой стиль.
5-10 лет. Отстаешь от других и просто кодишь сам в том стиле который нравится тебе.
10-15 лет. Не позволяешь другим себя переучивать. Идешь лишь на мелкие уступки.
16-17 лет. Меньше пустозвонства - чтобы не поссорится о стиле кодинга не говорим, моветон - аналогично обсуждать политику, или зарплату.
17-18 лет. пофиг какой стиль, читать можешь что угодно, но если скобки стоят не так как нужно - не понятно что написано.
19-20 лет. увольнять если используешь пробелы вместо табов - кажется правильная идея :)
Вы сами понимаете, что этого мало? Что как минимум в раза 4 это меньше моего? Я же имел как минимум авторитетные источники, хотя бы банду 4 назвали бы и ссылку, где они такое говорили? Что это за манера такая, не зная оппонента думать, что он знает меньше вас?
Вот именно, за мозги новичков мы тут и боремся да? Ну, ок пусть так ...
Отвечать вам надо, почему вы думаете, что все что вы написали вообще имеет смысл обсуждать? Зачем мне с вами обсуждать ваши глупости? Ну выучились вы где-то не так ... мне что до этого?
Вам объяснить и так надо ...
Почему вы позволили себе использовать переменную var в строготипизированном языке?
Почему вы бесполезно ввели лишнею переменную behaviorName
if (IsDoneBinding(BindingBehavior[i].Name) == false) - нет именно так и надо, почему вы предпочитаете "усложняющую чтение визуальную нагрузку" аналог ?
Почему вы позволяете себе return в методе ничего не возвращающем, почему не используете goto?
Поэтому не надо тут про "очевидные для более опытного разработчика вещи" - это бред в таких головах, который настоящим программистам сейчас все сложнее становится выбивать из молодежи.
И нет, вы позволили себе - учить меня тому, чего я не просил! Учить тому, что как минимум спорная практика, да спорная! Кто вам скажет, если не такие как я ... больше читайте теории, в голове будет еще больше каши. Вы мне еще расскажите как скобки ставить ...
И все это при том, что статья совершенно о другом. Вы утрудили себя хотя бы прочитать предыдущую статью, разобрать в этой и понять когда нужен MVC, и как его учат использовать? А ведь учили там тоже мол учитель в МФТИ с опытом коммерческой разработки ...
Только я подымаю темы серьезные, где надо понимать предмет, а не умничать про три копейки доступа по индексу - смешно. И таких ютуберов, которые по стилю кода позволяют себе что-то то сумничать - надо палками гнать из профессии. (Это не про вас лично, есть один чудак в ютубе, просто вы идете по его стопам, остановитесь ... )
И таки да, вы меня подзавели очевидными глупостями, которые даже обсуждать смешно ... но не я это начал ..
ну договаривайте ... тогда и поговорим ... когда, же мне начинают говорить, полунамеками, не утруждая себя никаким аргументированным тезисом, да еще ad hominem - о чем говорить?
P.S. А о качестве кода я лучше знаю, чем любая автоматизированная шняга ... скорее будут вопросы к её разработчикам.
Вы не правы по всем пунктам, я пояснять не буду. Но прежде, чем придираться к мелочам, начните правильно использовать MVC. Захотите от меня ответов - спросите уважительнее.
Серьезно? артист пишет такой код? кого вы пытаетесь насмешить, и тем самым оправдать применение MVC ради самого применения?
Может для декомпозиции кода, нужно не MVC использовать? И не только коде стайл использовать популярный, который просто кричит глупостями?
Так как это настолько часто возникающая несуразица, я лишь спрошу где источник этого несерьезного утверждения? Вы думаете, заменив это на return вы сделали лучше? Тогда я посоветую вам использовать goto они позволяют убрать больше if :)
P.S. Вы просто думайте, когда насмотревшись по ютубу всяких умников, начинаете учить других ... а то, что это советы от умников - аж сквозит ...
Клиентам - совершенно неважна лирика про архитектуру, Сережа - просто демпингует на рынке, ну и понятно, что история не реальная - лирика ... вообще, я вначале посмотрел бы код Сережи, может так статься, что и не так все плохо, т.к. "мозги" испорченные паттернами восстановить иногда еще сложнее ... но и обратный случай был только был это Каспарс - уволился под моим нажимом ... но начальство хорошо вспоминало, потому что я просил адекватную зарплату, а он работал сколько давали, а клиенты хотели скидку с демпинговой цены гос. закупок ... в итоге не бизнес, а утопия. Может и правда, пусть Сережа программирует, и по ночам исправляет свои баги, потому что клиенты уже не хотели платить за поддержку ... А зажравшимся мордам как я лучше найти коммерческую разработку, а не по гос. дешевизне, чтобы есть пельмени и пахать как индус 12 часов
Ах, да ... походите на Агил сброды, послушайте менеджеров о их пользе, и тогда Сережа будет идеальным для вас программистом ... Только не забываете, что это не больше чем психологическая атака, чтобы сбить цену разработки за счет программистов.
Удалите менеджерский сброд, и Сереж в компании, автоматом не будет