Использование заводского образца

Перед тем, как применить шаблон, вы должны иметь четкое представление о том, что вы получаете, делая это, и в этом случае я действительно не вижу, что введение статического "Factory" набирает вас. Посмотрите на это с точки зрения клиента PacketFactory: он представил его, уменьшив связь между клиентом и различными конкретными исполнителями IPacket? Я бы не утверждал, что, поскольку клиент уже должен знать, какой тип IPacket он хочет, указав значение перечисления либо PacketType.Info, PacketType.Message, либо PacketType.Log. Как это отличается от клиента, знающего о классах Info, Message и Log? Поскольку "Factory" является статическим классом, клиент так же связан с возвращаемым типом IPacket, как и если бы он просто вызвал конструктор соответствующего конструктора IPacket, потому что вам пришлось бы изменить клиент для того, чтобы он работал с другим типом IPacket в любом случае.

Итак, если вы действительно должны использовать какой-либо Factory, я бы предложил использовать шаблон Abstract Factory, чтобы клиенты Factory зависели только от интерфейса Factory и поэтому способный работать с различными типами IPacket без необходимости изменения. Например:

public interface IPacketFactory
{
   IPacket CreatePacket();
   IPacket CreatePacket(Client creator, DateTime creationTime, string data);
}

public class MessageFactory : IPacketFactory
{
   public CreatePacket()
   {
      return new Message();
   }

   public CreatePacket(Client creator, DateTime creationTime, string data)
   {
      return new Message(creator, creationTime, data);
   }
}

//You'd implement factories for each IPacket type...

public class Client
{
   private IPacketFactory _factory;

   public Client(IPacketFactory factory)
   {
      _factory = factory;
   }

   public SomeMethodThatNeedsToCreateIPacketInstance()
   { 
      IPacket packet = _factory.CreatePacket();

     //work with packet without caring what type it is
   }

}


//a higher level class or IOC container would construct the client with the appropriate factory

Client client = new Client(new MessageFactory());

// the Client class can work with different IPacket instances without it having to change (it decoupled)

Client client2 = new Client(new LogFactory());

Насколько Factory должен позволить построить IPacket без указания создателя, данные и время создания или не зависят от инвариантов класса. Если инварианты класса могут выполняться, когда поля не указаны, то это прекрасно, в противном случае они должны быть необходимы. Часть задания класса должна состоять в том, чтобы убедиться, что он не может быть сконструирован в недопустимом состоянии, поскольку пользователи этого класса будут в зависимости от того, что будет.

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

Образец Factory нуждается в том, чтобы он был единым интерфейсом для всех исполнителей, поэтому, если для всех фабрик имеет смысл использовать метод Create с дополнительными параметрами, вы можете добавить их в интерфейс. Одна из форм заключается в передаче объекта с различными свойствами/методами, которые метод Create может использовать для получения дополнительных значений параметров, которые ему нужны. Особым случаем является Double Dispatch, где вызывающий абонент сам передает (в данном случае Клиент) и затем вызывается из метода Create.

//in MessageFactory : the PacketContext holds various data that may be relevant to creation

public IPacket Create(Client creator, DateTime creationTime, string data, PacketContext ctx)
{
   return new Message(creator, creationTime, data, ctx.SomeExtraData); 
}

//in LogFactory: the Log doesn't need anything from the PacketContext but it does call something on the Client (Double Dispatch)

public IPacket Create(Client creator, DateTime creationTime, string data, PacketContext ctx)
{
   return new Log(creator.Name, creationTime, data);
}

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

public class MessageFactory : IPacketFactory
{
   private object _data;

   public MessageFactory(object extraData)
   {
      _data = extraData;
   }

    IPacket CreatePacket(Client creator, DateTime creationTime, string data)
    {
       return new Message(creator, creationTime, data, _extraData);
    }

    ///rest of implementation
}

Те представляют некоторые из параметров, но в любом случае я бы настоятельно рекомендовал, чтобы вы не использовали статический или одиночный класс "Factory" , потому что он будет сильно сочетать ваш клиентский класс с Factory и большинством вероятно, подкласс IPacket.