Ответы пользователя по тегу C#
  • Смысл интерфейса (не GUI) и зачем он вообще нужен?

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

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

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

    @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 комментария