Плохо ли если класс самодостаточен, в плане получения каких то данных необходимых для его полноценной работы? Не могу решить как правильнее будет действовать в такой ситуации. примерчик:public class Model { public Model(int id, string path) { ID = id; Path = path; } public int ID { get; protected set; } public string Path { get; protected set; } } public class UpgradeModelA : Model { public UpgradeModelA(int id, string path) : base(id, path) {
} public void Method1() { } } /// /// Вариант 1: child элементы я получаю из репозитория вне класса, после чего вызываю конструктор передавая туда параметры /// public class UpgradeModelB : Model { public UpgradeModelB(int id, string path, IEnumerable children) : base(id, path) { Children = children; } public void Method2() { } public IEnumerable Children { get; protected set; } } /// /// Вариант 2: child элементы я получаю из репозитория внутри класса, внутри конструктора /// public class UpgradeModelB : Model { public UpgradeModelB(int id, string path) : base(id, path) { Children = Repository.getItemsByParentID(id); } public void Method2() { } public IEnumerable Children { get; protected set; } } Тоесть хорошо ли или плохо всё же когда классы самодостаточны, и наполняются данными к примеру сами пользуюясь репозиториями, либо же стоит жёстко розграничивать получение/обновление данных в классе.
Вопрос о том, стоит ли классу быть самодостаточным в получении данных, зависит от конкретной ситуации и требований к архитектуре вашего приложения.
В вашем примере оба варианта имеют право на существование и могут быть использованы в зависимости от конкретных потребностей.
Вариант 1 (получение child элементов извне и передача их в конструктор) может быть более гибким и позволит использовать класс UpgradeModelB с различными наборами Child элементов без необходимости изменения самого класса.
Вариант 2 (получение child элементов внутри класса) может быть удобен в случае если данные Child элементов обязательно должны быть получены именно вместе с основным объектом UpgradeModelB и иметь единую логику обработки.
Также стоит учитывать принцип единственной ответственности (Single Responsibility Principle) - класс должен быть ответственен только за одну четко определенную задачу. Если получение данных для класса не является его основной задачей, возможно лучше вынести эту логику в отдельный класс или сервис.
Таким образом, вам следует анализировать конкретные требования и особенности вашего приложения для определения того, какой подход будет наиболее подходящим в каждом конкретном случае.
Вопрос о том, стоит ли классу быть самодостаточным в получении данных, зависит от конкретной ситуации и требований к архитектуре вашего приложения.
В вашем примере оба варианта имеют право на существование и могут быть использованы в зависимости от конкретных потребностей.
Вариант 1 (получение child элементов извне и передача их в конструктор) может быть более гибким и позволит использовать класс UpgradeModelB с различными наборами Child элементов без необходимости изменения самого класса.
Вариант 2 (получение child элементов внутри класса) может быть удобен в случае если данные Child элементов обязательно должны быть получены именно вместе с основным объектом UpgradeModelB и иметь единую логику обработки.
Также стоит учитывать принцип единственной ответственности (Single Responsibility Principle) - класс должен быть ответственен только за одну четко определенную задачу. Если получение данных для класса не является его основной задачей, возможно лучше вынести эту логику в отдельный класс или сервис.
Таким образом, вам следует анализировать конкретные требования и особенности вашего приложения для определения того, какой подход будет наиболее подходящим в каждом конкретном случае.