Разделение проблем / структурирование кода в среде на основе классов (C# используется в качестве примера)

Question

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

Пример 1

Файлы проекта

• Api.cs
• Типы данных
  • Anime.cs
  • Episode.cs

Api.cs

public class Api
{
    public static async Task<List<Anime>> GetAnimesByKeyword(string keyword)
    {
        // Execute api request to server
        return result;
    }

    public static async Task<List<Episode>> GetEpisodesByAnime(Anime anime)
    {
        // Execute api request to server
        return result;
    }

}

DataTypes -> Anime.cs

public class Anime
{
    public string Name { get; set; }
    public string Summary { get; set; }
    // Other properties
}

DataTypes -> Episode.cs

public class Episode
{
    public string Name { get; set; }
    public Date ReleaseDate { get; set; }
    // Other properties
}

Или пример 2

Файлы проекта

• Api.cs
• Типы данных
  • Anime.cs
  • Episode.cs

Api.cs

public class Api
{
    // Nothing for now
}

DataTypes -> Anime.cs

public class Anime
{
    public static async Task<Anime> GetById(int id)
    {
        return result;
    }

    public string Name { get; set; }
    public string Summary { get; set; }
    // Other properties
}

DataTypes -> Episode.cs

public class Episode
{
    public static async Task<List<Episode>> GetEpisodesByAnime(Anime anime)
    {
        return result;
    }

    public string Name { get; set; }
    public Date ReleaseDate { get; set; }
    // Other properties
}

Что из этих 2 является предпочтительным способом структурирования кода, или есть лучший способ сделать это. Это может показаться незначительным, но это имеет значение для меня.

Спасибо за помощь мне!

Answer 1

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

Ваш второй пример объединяет проблемы и тесно связывает эти два класса (Episode теперь зависит от Anime). Вы также можете увидеть, как трудно решить, к какому классу добавить этот метод загрузки: anime.GetEpisodes() или же Episode.GetEpisodesByAnime()? Поскольку граф объекта становится более сложным, это возрастает.

Позже вы можете захотеть другой объект передачи данных для объекта. Наличие простых объектов только для данных позволяет легко добавлять их и использовать Automapper преобразовать.

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