Нарушаю ли я принцип единой ответственности (SRP), если использую методы «доступа к данным» для бизнес-объекта? Мне кажется, что API кажется более удобным для пользователя, если метод Load присутствует в самом классе, вместо того, чтобы угадывать, к какому классу относится этот метод?
Пример:
public class Image
{
public static Image FromFile(string filename)
{
return ImageLoader.LoadImage(filename)
}
public void SetPixel(int x, int y, Color color)
{
}
}
я не вижу проблемы с этим per se, за исключением того, что нет веских причин для того, чтобы статический метод жил в классе Image (поскольку он не зависит от чего-либо в классе, но от сам класс).
если у вас будет куча методов загрузки, они могут быть лучше в другом классе
В общем, я не думаю, что знание того, как создать экземпляр себя с помощью единственного пути (в данном случае из файла изображения) и обеспечение допустимого состояния обязательно затрудняет SRP. Если бы у вас было множество таких методов, это было бы запахом кода, и тогда вы должны уловить намек, чтобы разделить вещи.
Я думаю, что тот факт, что он статичен, делает его менее «вопиющим» нарушением SRP, но я не самый большой пурист SOLID. К подобным эвристикам не следует относиться слишком строго ...
В каком-то смысле да, но это не так плохо, как вы думаете. Любой принцип можно довести до крайности, что сделает его неудобным.
Вопрос в том, что, если позже вы захотите, чтобы они были разделены, потому что вы хотите, чтобы эта статика применялась к другим изображениям, или вы хотите реализовать гораздо более сложный метод, который может применяться к другим типам данных.
В общем, рефакторинг java достаточно прост, поэтому я предлагаю вам использовать то, что имеет смысл сейчас, и просто не забудьте вернуться к нему всякий раз, когда кажется, что это может привести к отмене сложности.
