Статическая фабрика на бизнес-объекте является нарушением принципа единой ответственности?

Question

Нарушаю ли я принцип единой ответственности (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)
   {
   }
 }

Answer 1

Я не вижу проблем с этим как таковым , за исключением того, что нет никаких веских причин для статического метода жить в классе Image (так как он не зависит ни от чего в классе, но по самому классу).

если в итоге вы получите кучу методов загрузки, они могут быть лучше в другом классе

Answer 2

В некотором смысле, да, но это не так плохо, как вы думаете. Любой принцип можно довести до крайности, что делает его неудобным.

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

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

Answer 3

Я думаю, что тот факт, что он статичен, делает его менее «вопиющим» нарушением SRP, но я не самый большой твёрдый пурист. Такого рода эвристики не следует воспринимать слишком религиозно ...

Answer 4

В общем, я не думаю, что знание того, как создать экземпляр себя по одному пути (в данном случае, из файла изображения) и обеспечения действительного состояния, обязательно приводит к перегрузке SRP. Если бы у вас было множество таких методов, это было бы запахом кода, и тогда вы должны взять подсказку, чтобы отделить вещи.