Не заметил. Тогда ооп применимо в таких местах. Архитектура фреймворков отличается
Но все равно Action - объект который не вписывается в иерархию.
У вас уже есть PermissionService. Это он дожен вызывать запросы, и в нем должна быть бизнес-логика. Хотя непонятно назначение PermissionService, разве запросов на доступ будет много? Но очевидно что он зависит от более общего RequestService. ViewModel страницы вызывает уже IRequestService и заполняет Model, про сервер и запросы она ничего не знает.
Сущность Action - не имеет смысла. Количество запросов будет все время расти и изменятся, наследование этому помешает. Тут можно использовать паттерн стратегия, когда увеличется количество.
Сущность делает не свое дело и варинципе не нужна.
Нарушение принципоsolid
Не используйте ООП внутри архитектуры, тем более наследование
Нейминг сущностей важнее кода.
Логика и данные должны быть отделены.
Минимизировать зависимости.
Сущность использует сеть для запроса, следовательно она должна обратиться к сервису запросов. Значит у нее очень большая власть. Но как только вы правильно назовёте класс, то станет очевидным что эта сущность в принципе не нужна. Ваша тезис оказался верным.
ТРИЗ и системный анализ - работают. Но без практики это полностью бесполезно. Это больше про особое мышление разработчика, и некоторые интуитивно понятные методики. Вся суть в творчестве, а творчество - это эмерджетный эффект системы в игре хаоса. Результат непредсказуем по определению. Разработчик - это лишь оценщик и наблюдатель.
Задача найти неизвестное, новое, крутое, простое, среди бесконечного числа варинатов - это стандартная задача разрабочика. Либо сделать из бага фичу - один из любимых приемов.
Например, недавно разрабатывали мундштук для сасафона - неизвестная область для меня. Использовал эволюционые алгоритм, триз и системный анализ. В итоге удалось создать несоклько уникальных инструмента с новыми свойствами, даже без знаний и опыта. Но в материальном у эволюционных методов есть несколько проблем - это сложные и долгие итерации, и проблема точности и измерений. Ушло сотни попыток, и десятки итераций, много денег и 1.5 года. Лушче все же сначала построить модели.
Другой пример - это вейпы. Там пионеры учередили совместную разработку. Благодаря этому вейпы выглядит имеено так и являются обслуживаемыми. Иначе бы были бы неудобные конструкции с незаменяемые картиджами. Там мы тоже использовали метод перебора.
В IT методов разработки еще больше и нет проблем материального мира. Автоматизировать творчетсво вполне возможно.
Нифига себе слабое. Дефракция способна отклонить свет на градусов 30, может и больше. Гравитация слабее влияет, но то же солнце отклоняет свет на градусов 5, при этом уже дефракции нет.
Ну любое взаимодетсвие света и материи вызывает дефракцию, что вызывает интерференцию.
В идеале, нужно осветить один атом водорода лазером с частотой спектра водорода. Тогда интерференция будет максимальной и сам атом будет испускать фотоны. Вроде так и работает сам лазер.
А если осветить тем же лазером полученное интерферционное изображение, то получим изображение атома. На таком принцепе работают тонкие голограммы и птихография.
Таким собствено способом и были получены изображения атомов.
Физическая точка - это всегда окружность определеного диаметра. В этой области будет интерференция, в сумме энергия будет такой же.
Если освтетить экран 2-мя когерентыми источниками - то появится интереференция фазовой приророды. Если луч взаимодествует с любой материей - то появится уже интерфернция дефракционной природы. Так же свет взаимодествует и с гравитацией, но если не ошибаюсь, интерференции тут не будет.
Тут магия, свет отправился в будущее и решил стать волной. Типичные физики-теоретики...
Тут лазер+экран, который перекрывает луч на половину, без всяких щелей и капель. Луч при этом летит уже не по прямой. Интерфереция всегда работает, это специфика дефракции. Если ее не видно, значит свет ее просто рассеял.
Для квантового эксперемента нужно смотреть интереференцию одного кванта с самим собой, иначе это не имеет смысла. Квант - это минимальная порция волн.
А вообще, можно ли прикастыливать идеалистические теории к науке? Зачем и на каком основании британцкие ученые так усердно пытаются впихнуть бога, многомирия и симуляцию?
В эксперименте ключевое условие - запускать фотоны строго по "одному" и расстояние между отверстиями должно быть меньше длины волны. Иначе никакого смысла не имеет, интереференция будет в любом случае, даже если щель будет только одна. Да даже если не будет ни одной щели, фотоны будут огибать любое препятствие.
Программирование - это уже раздел прикладной математики, кибернетики. Спор абсурден, хоти или нет, вы прикладники. Да бонально, чтобы прочитать пейперы, нужен довольно высокий уровень математики. Как-то раз читал 2 страницы 2 года.
Проблема математики - в крайне низком уровне образования в школах и вузах, кроме матшкол. При этом прикладную математику можно понять лишь на практике, так сказать прикладывать ее)
А чтобы кодить - ума не надо. Этот процесс пора автоматизировать.
Бизнес-логика дается сверху, и она всегда неполна и не рассматривает все состояния.
Если в коде два "if", то энтропия кода будет 4, т.е 4 возможных состояния.
Если в коде 8 if, то энтропия уже 256. В спагетти-коде энтропия больше чем гугол. Программист обязан все эти состояния проверить, причем если добавить условия проверки, то это только увеличит энтропию.
Это уже сложная система, в сложных системах всегда возникают непредсказуемые системные эффекты.
Цель разработки - в поиске полезных системных эффектов и чтобы система не погрязла в хаосе. Разработка итерационная.
SOLID - это типичное кибернетическое управление, причем единственное. Есть и некибернетические подходы.
От архитектуры зависит все. Зависит время жизни проекта, состав команды, время жизни компании, и сам проект и его фичи.
Задача программиста не в написании кода, а в уменьшении сложности и связанности. Книгу пишет не машинистка.
Хороший код - это оптимальный код при заданных условиях и задачи. Любой говнокод увеличивает сложность кода и время разработки, да и вообще не имеет плюсов.
Для этапа разработки критически важно качество кода, тратить большую часть времени и усилий на бессмысленный багфикс - это тупо даже с точки зрения бизнеса.
Код-ревью - это в превую очередь обучение сотрудников, и ревьювит вся команда. На ревьювера ложится прямая ответственность, если он пропустил говно-код.
Изменять и рефакторить код на продакшене уже нельзя, тем более легаси. И на этом этапе уже не будет выбора, а переписывать с 0 уже не разумно.
PS Нужно не забывать, что гит помнит наши имена и наши правки.
Дядюшка Боб молодец, литература строго обязательна.
Весь смысл SOLID в декомпозиции и в минимизации энтропии кода. Это проектирование через data driven подход, в отделении чистой логики и данных.
Какой смысл в иерархий тестов? Все тесты должны проходить и независимы. Писать unit-тесты на логику ui - это ошибка. Для этого существуют авто-тесты.
Для gui подойдет MVVM+DI или подобные шаблоны. А вот уже чистую логику нужно покрывать юнит-тестами, сделать это просто, логика всегда простая и ее мало.
Переписать легаси на SOLID весьма болезненно и зачастую невозможно уложиться в разумные сроки, но подход правильный.
Формулы поддерживает лишь wolfram и подобный математические языки. На других писать формулы невероятно неудобно и нечитаемо. Более менее удобно на F# и прочих функциональных языках.
Обычно оставляют ссылку на саму формулу на сайте. А переменные называют строго как по ссылке.
1) Сквошить комиты нельзя - история гита должна быть полной и жить до конца проекта.
2) Микро-комиты - полезная тема, много раз спасали. Делает историю легко читаемой и просто ревертить. В гите для этого есть построчные комиты. Еще комиты обязаны быть залинкованы с номером задачи.
3) Merge commit уродует историю и ветки. Неоднократно были серьезные проблемы с неверным мерджем, найти такие баги очень сложно. Rebase - более надежно, можно и без fast-forward.
4) develop - активно-рабочая ветка. Для этого нужно, чтобы merge-request проходил как можно скорее и вливался в develop.
5) Проблемы только с release-ветками, их приходиться собирать черепиками, благо все комиты последовательны.
6) Очень длительные ветки для фичей - зло. Где-то используют фитч-флаги для этого. Вливают недоделанную фичу и блокируют ее кодом. Но непонятно как красиво такое реализовать.
Не заметил. Тогда ооп применимо в таких местах. Архитектура фреймворков отличается
Но все равно Action - объект который не вписывается в иерархию.
У вас уже есть PermissionService. Это он дожен вызывать запросы, и в нем должна быть бизнес-логика. Хотя непонятно назначение PermissionService, разве запросов на доступ будет много? Но очевидно что он зависит от более общего RequestService. ViewModel страницы вызывает уже IRequestService и заполняет Model, про сервер и запросы она ничего не знает.
Сущность Action - не имеет смысла. Количество запросов будет все время расти и изменятся, наследование этому помешает. Тут можно использовать паттерн стратегия, когда увеличется количество.
Каждый из вариантов - говнокод
Нейминг
Применение ООП не в том месте и ещё и с логикой
Перепутаны зависимости.
Сущность делает не свое дело и варинципе не нужна.
Нарушение принципоsolid
Не используйте ООП внутри архитектуры, тем более наследование
Нейминг сущностей важнее кода.
Логика и данные должны быть отделены.
Минимизировать зависимости.
Сущность использует сеть для запроса, следовательно она должна обратиться к сервису запросов. Значит у нее очень большая власть. Но как только вы правильно назовёте класс, то станет очевидным что эта сущность в принципе не нужна. Ваша тезис оказался верным.
Текстурные массивы разве не поддерживает gles 3.1? Они куда лучше.
ТРИЗ и системный анализ - работают. Но без практики это полностью бесполезно. Это больше про особое мышление разработчика, и некоторые интуитивно понятные методики. Вся суть в творчестве, а творчество - это эмерджетный эффект системы в игре хаоса. Результат непредсказуем по определению. Разработчик - это лишь оценщик и наблюдатель.
Задача найти неизвестное, новое, крутое, простое, среди бесконечного числа варинатов - это стандартная задача разрабочика. Либо сделать из бага фичу - один из любимых приемов.
Например, недавно разрабатывали мундштук для сасафона - неизвестная область для меня. Использовал эволюционые алгоритм, триз и системный анализ. В итоге удалось создать несоклько уникальных инструмента с новыми свойствами, даже без знаний и опыта. Но в материальном у эволюционных методов есть несколько проблем - это сложные и долгие итерации, и проблема точности и измерений. Ушло сотни попыток, и десятки итераций, много денег и 1.5 года. Лушче все же сначала построить модели.
https://youtu.be/KFWWYZp4V28
Другой пример - это вейпы. Там пионеры учередили совместную разработку. Благодаря этому вейпы выглядит имеено так и являются обслуживаемыми. Иначе бы были бы неудобные конструкции с незаменяемые картиджами. Там мы тоже использовали метод перебора.
В IT методов разработки еще больше и нет проблем материального мира. Автоматизировать творчетсво вполне возможно.
Впервые слышу о такой профессии. Есть бета-тестировщики, есть QA.
QA- входить в отдел разработки, и программируют они не меньше программистов.
А бета-тестеры - это не проффессия.
Непонятно почему linq на c# такой убогий. На f# он прекрасен, мощный и без всяких аллокаций, хотя платформа одна и та же.
Нифига себе слабое. Дефракция способна отклонить свет на градусов 30, может и больше. Гравитация слабее влияет, но то же солнце отклоняет свет на градусов 5, при этом уже дефракции нет.
Ну любое взаимодетсвие света и материи вызывает дефракцию, что вызывает интерференцию.
В идеале, нужно осветить один атом водорода лазером с частотой спектра водорода. Тогда интерференция будет максимальной и сам атом будет испускать фотоны. Вроде так и работает сам лазер.
А если осветить тем же лазером полученное интерферционное изображение, то получим изображение атома. На таком принцепе работают тонкие голограммы и птихография.
Таким собствено способом и были получены изображения атомов.
Физическая точка - это всегда окружность определеного диаметра. В этой области будет интерференция, в сумме энергия будет такой же.
Если освтетить экран 2-мя когерентыми источниками - то появится интереференция фазовой приророды. Если луч взаимодествует с любой материей - то появится уже интерфернция дефракционной природы. Так же свет взаимодествует и с гравитацией, но если не ошибаюсь, интерференции тут не будет.
Тут магия, свет отправился в будущее и решил стать волной. Типичные физики-теоретики...
Тут лазер+экран, который перекрывает луч на половину, без всяких щелей и капель. Луч при этом летит уже не по прямой. Интерфереция всегда работает, это специфика дефракции. Если ее не видно, значит свет ее просто рассеял.
Для квантового эксперемента нужно смотреть интереференцию одного кванта с самим собой, иначе это не имеет смысла. Квант - это минимальная порция волн.
А вообще, можно ли прикастыливать идеалистические теории к науке? Зачем и на каком основании британцкие ученые так усердно пытаются впихнуть бога, многомирия и симуляцию?
В эксперименте ключевое условие - запускать фотоны строго по "одному" и расстояние между отверстиями должно быть меньше длины волны. Иначе никакого смысла не имеет, интереференция будет в любом случае, даже если щель будет только одна. Да даже если не будет ни одной щели, фотоны будут огибать любое препятствие.
Лучше сначала изучить функциональное программирование. Потом SOLID. Тогда эти паттерны станут очевидными.
Head First - можно прочитать для ознакомления. Вторая уже устарела, как и объектно-ориентированное проектирование.
Программирование - это уже раздел прикладной математики, кибернетики. Спор абсурден, хоти или нет, вы прикладники. Да бонально, чтобы прочитать пейперы, нужен довольно высокий уровень математики. Как-то раз читал 2 страницы 2 года.
Проблема математики - в крайне низком уровне образования в школах и вузах, кроме матшкол. При этом прикладную математику можно понять лишь на практике, так сказать прикладывать ее)
А чтобы кодить - ума не надо. Этот процесс пора автоматизировать.
Лучше тогда сразу F#, он от Ocaml и произошел.
F# позволяет писать не только в функциональном стиле, но и в императивном, и напрямую C#-ом.
Это не так. Архитектура - это воля кибернетики.
Бизнес-логика дается сверху, и она всегда неполна и не рассматривает все состояния.
Если в коде два "if", то энтропия кода будет 4, т.е 4 возможных состояния.
Если в коде 8 if, то энтропия уже 256. В спагетти-коде энтропия больше чем гугол. Программист обязан все эти состояния проверить, причем если добавить условия проверки, то это только увеличит энтропию.
Это уже сложная система, в сложных системах всегда возникают непредсказуемые системные эффекты.
Цель разработки - в поиске полезных системных эффектов и чтобы система не погрязла в хаосе. Разработка итерационная.
SOLID - это типичное кибернетическое управление, причем единственное. Есть и некибернетические подходы.
От архитектуры зависит все. Зависит время жизни проекта, состав команды, время жизни компании, и сам проект и его фичи.
Задача программиста не в написании кода, а в уменьшении сложности и связанности. Книгу пишет не машинистка.
Хороший код - это оптимальный код при заданных условиях и задачи. Любой говнокод увеличивает сложность кода и время разработки, да и вообще не имеет плюсов.
Для этапа разработки критически важно качество кода, тратить большую часть времени и усилий на бессмысленный багфикс - это тупо даже с точки зрения бизнеса.
Код-ревью - это в превую очередь обучение сотрудников, и ревьювит вся команда. На ревьювера ложится прямая ответственность, если он пропустил говно-код.
Изменять и рефакторить код на продакшене уже нельзя, тем более легаси. И на этом этапе уже не будет выбора, а переписывать с 0 уже не разумно.
PS Нужно не забывать, что гит помнит наши имена и наши правки.
Дядюшка Боб молодец, литература строго обязательна.
Весь смысл SOLID в декомпозиции и в минимизации энтропии кода. Это проектирование через data driven подход, в отделении чистой логики и данных.
Какой смысл в иерархий тестов? Все тесты должны проходить и независимы. Писать unit-тесты на логику ui - это ошибка. Для этого существуют авто-тесты.
Для gui подойдет MVVM+DI или подобные шаблоны. А вот уже чистую логику нужно покрывать юнит-тестами, сделать это просто, логика всегда простая и ее мало.
Переписать легаси на SOLID весьма болезненно и зачастую невозможно уложиться в разумные сроки, но подход правильный.
Формулы поддерживает лишь wolfram и подобный математические языки. На других писать формулы невероятно неудобно и нечитаемо. Более менее удобно на F# и прочих функциональных языках.
Обычно оставляют ссылку на саму формулу на сайте. А переменные называют строго как по ссылке.
Прибывал все эти git workflow и согласен с тс.
1) Сквошить комиты нельзя - история гита должна быть полной и жить до конца проекта.
2) Микро-комиты - полезная тема, много раз спасали. Делает историю легко читаемой и просто ревертить. В гите для этого есть построчные комиты. Еще комиты обязаны быть залинкованы с номером задачи.
3) Merge commit уродует историю и ветки. Неоднократно были серьезные проблемы с неверным мерджем, найти такие баги очень сложно. Rebase - более надежно, можно и без fast-forward.
4) develop - активно-рабочая ветка. Для этого нужно, чтобы merge-request проходил как можно скорее и вливался в develop.
5) Проблемы только с release-ветками, их приходиться собирать черепиками, благо все комиты последовательны.
6) Очень длительные ветки для фичей - зло. Где-то используют фитч-флаги для этого. Вливают недоделанную фичу и блокируют ее кодом. Но непонятно как красиво такое реализовать.