Задать вопрос
  • Какое будущее ждёт ASP.NET WebForms?

    @nexus478
    Будущего у самой технологии нет, но есть проекты, которые надо поддерживать. Так что на самом деле работу найти можно (на hh периодически попадаются вакансии), но это будет максимум легаси со всеми вытекающими. А с чего вообще такой вопрос?
    Ответ написан
  • Смысл интерфейса (не GUI) и зачем он вообще нужен?

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

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

    Интерфейс позволяет переключаться между реализациями, когда меняется контекст, при этом клиент интерфейса от этого контекста не зависит, можно сказать, что интерфейс позволяет отгораживаться от переменчивого контекста. А обязательство реализации требуется для того, чтобы гарантировать клиенту интерфейса, что он получит нужные данные.
    Ответ написан
    Комментировать
  • С какой книги начать изучение проектирования по?

    @nexus478
    Проектирование приложений можно условно разбить на 2 уровня:
    1. Уровень проекта.
    Сюда входит понимание того, как приложение должно выглядеть в целом и из каких компонентов состоять, а также по каким принципам оно собирается взаимодействовать с внешним миром (если есть такая необходимость). Компоненты зависят от выбранной архитектуры - в случае монолитного приложения вам требуется понимать, как разбивать его на слои и в чем ответственность каждого слоя; в случае микросервисов вы также должны понимать, как очерчивать зоны ответственности и определять протоколы взаимодействия между ними.
    Книги о том, как проектировать приложения на общем уровне:
    1. Роберт Мартин. Чистая архитектура - очень короткая и простая книга, рекомендую начать с неё.
    2. Эрик Эванс. Предметно-ориентированное проектирование (принципы + стратегические шаблоны).
    3. Мартин Фаулер. Архитектура корпоративных приложений (часть 1).

    Уровень 2. Уровень модулей (классов).
    Когда вы спроектировали компоненты, из которых состоит ваше приложение, теперь надо спроектировать их внутренности - то есть разбить на более мелкие и конкретные модули. Тут вам пригодятся принципы объектно-ориентированное проектирования, принципы SOLID, паттерны.
    Книги по уровню 2.
    1. Банда четырех. Приёмы объектно-ориентированного проектирования. Паттерны проектирования. Тут важно не только сами паттерны, но принципы, по которым они строятся. Концентрируйтесь на принципах.
    2. Роберт Мартин. Принципы, паттерны и методики гибкой разработки на языке C#. Тут более подробно рассматривается объектно-ориентированный дизайн и принципы SOLID в сравнении с его "Чистой архитектурой".
    3. Эрик Эванс. Предметно-ориентированное проектирование (тактические шаблоны).
    4. Мартин Фаулер. Архитектура корпоративных приложений (часть 2).
    5. Стивен Макконел. Совершенный код (сконцентрируйтесь на понимании Главного Технического Императива!).

    Этих книг вам будет достаточно, чтобы ориентироваться в проектировании приложений, всё остальное решает практика. Рисуйте схемы, концентрируйтесь на ответственности компонентов и их интерфейсах, учитесь отбрасывать ненужные детали реализации.
    Ответ написан
    Комментировать
  • Как научиться проектировать ПО?

    @nexus478
    Проектирование приложений можно условно разбить на 2 уровня:
    1. Уровень проекта.
    Сюда входит понимание того, как приложение должно выглядеть в целом и из каких компонентов состоять, а также по каким принципам оно собирается взаимодействовать с внешним миром (если есть такая необходимость). Компоненты зависят от выбранной архитектуры - в случае монолитного приложения вам требуется понимать, как разбивать его на слои и в чем ответственность каждого слоя; в случае микросервисов вы также должны понимать, как очерчивать зоны ответственности и определять протоколы взаимодействия между ними.
    В вашем случае я думаю вряд ли микросервисы будут актуальны (они для больших проектов), поэтому у вас скорее всего будут небольшие монолитные приложения.
    Книги о том, как проектировать приложения на общем уровне:
    1. Роберт Мартин. Чистая архитектура - очень короткая и простая книга, рекомендую начать с неё.
    2. Эрик Эванс. Предметно-ориентированное проектирование (принципы + стратегические шаблоны).
    3. Мартин Фаулер. Архитектура корпоративных приложений (часть 1).

    Уровень 2. Уровень модулей (классов).
    Когда вы спроектировали компоненты, из которых состоит ваше приложение, теперь надо спроектировать их внутренности - то есть разбить на более мелкие и конкретные модули. Тут вам пригодятся принципы объектно-ориентированное проектирования, принципы SOLID, паттерны.
    Книги по уровню 2.
    1. Банда четырех. Приёмы объектно-ориентированного проектирования. Паттерны проектирования. Тут важно не только сами паттерны, но принципы, по которым они строятся. Концентрируйтесь на принципах.
    2. Роберт Мартин. Принципы, паттерны и методики гибкой разработки на языке C#. Тут более подробно рассматривается объектно-ориентированный дизайн и принципы SOLID в сравнении с его "Чистой архитектурой".
    3. Эрик Эванс. Предметно-ориентированное проектирование (тактические шаблоны).
    4. Мартин Фаулер. Архитектура корпоративных приложений (часть 2).
    5. Стивен Макконел. Совершенный код (сконцентрируйтесь на понимании Главного Технического Императива!).

    Этих книг вам будет достаточно, чтобы ориентироваться в проектировании приложений, всё остальное решает практика. Рисуйте схемы, концентрируйтесь на ответственности компонентов и их интерфейсах, учитесь отбрасывать ненужные детали реализации.
    Ответ написан
    1 комментарий
  • Номера ошибок. Требуется однократно указать номер ошибки в коде. Есть хорошая практика?

    @nexus478
    Сделайте отдельный класс, который будет хранить список условий или отдельное свойство типа
    Dictionary<int, bool>  (номер правила и нарушено/не нарушено)

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

    А вообще было бы неплохо узнать, как выглядит класс валидации и как выглядит класс-клиент, который ожидает коды ошибок.
    Ответ написан
  • Как реализовать эту функцию на C#?

    @nexus478
    Вам требуется паттерн Команда, он позволит избежать большого количества if-ов и при этом даст возможность добавлять гибко добавлять новые команды. Почитайте про этот паттерн на метаните, внимательно изучите схемы и постарайтесь понять, какую роль играет каждый участник паттерна.
    Примерно это может выглядеть вот так
    public interface ICommand
    {
        void Execute(CommandParameter parameter);
    }
    
    public class CommandParameter
    {
        public int Id { get; set; }
        public int Count { get; set; }
        // сюда можно добавлять сколько угодно новых параметров, 
        // которые вам требуется записывать в файл
    }
    
    public class AddHealthCommand : ICommand
    {
        public void Execute(CommandParameter parameter)
        {
            File.WriteAllText(@"D:\path.txt", $"player.modav health {parameter.Count}");
        }
    }
    
    public class AddItemCommand : ICommand
    {
        public void Execute(CommandParameter parameter)
        {
            File.WriteAllText(@"D:\path.txt", $"player.additem {parameter.Id} {parameter.Count}");
        }
    }
    
    public class CommandWriter
    {
        public void WriteCommand(ICommand command, CommandParameter parameter)
        {
            command.Execute(parameter);
        }
    }


    Например, пользователь решил добавить здоровья, это будет выглядеть так
    var addHealthParameter = new CommandParameter {Count = value}; //value пришло откуда-то из интерфейса
    commandWriter.WriteCommand(new AddHealthCommand(), addHealthParameter);

    Если пользователь захочет добавить предмет, то запись будет выглядеть так
    var addItemParameter = new CommandParameter {Id = id, Count = count};
    commandWriter.WriteCommand(new AddItemCommand(), addItemParameter);


    И если вам захочется добавить новую команду, вы просто делаете наследника ICommand и реализуете там логику добавления. А класс CommandParameter даст вам гибкость в добавлении новых параметров в команды.

    У вас WPF или WinForms приложение, так ведь?
    Ответ написан
    Комментировать
  • Где найти практику?

    @nexus478
    Вам надо выбрать направление, в рамках которого собираетесь развиваться и использовать язык, а также соответствующий фреймворк. Если декстоп - WPF, если веб - ASP.NET MVC, если геймдев - Unity. Самому поначалу очень трудно придумать идею для проекта, поэтому могу посоветовать просто переписывать код из книг или ресурсов (например, на метаните есть разбор архитектур целых приложений, рекомендую практиковаться там). После этого у Вас будет маленькое приложение, к которому можете допиливать небольшие собственные фичи - сделать логирование, какие-либо новые режимы и бизнес-правила и т.д.

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