Service / API design patterns - which is the preferred approach?
===

I'm wrestling with two different design approaches to a fairly simple problem.

I have a service (in the generic sense, not Web/SOAP etc) that: 

 - Receives an `Input` class
 - Uses `Input` to process and create an `Output` class that is essentially just data, all dependent on the Input data.

The two different design approaches are as follows:

 - Use an `OutputCreator` class that knows how to create and populate the `Output` and leave the `Output` as basically a POCO. The  `OutputCreator` has all the processing logic, the `Output` is very simple and cannot be abused.
 - Alternatively, pass the `Input` directly to a particular type of `Output` class. Each type of `Output` knows how to process the `Input`, so it supports behaviour also. The key `Output` data would be defined by an interface which each different type of `Output` would implement.

The first approach means I can make all the processing logic internal to my service. The second means I don't need the `Creator` class with that logic being encapsulated, but I potentially expose more (plus it may violate SRP).

Which approach is closer to best practice?

Thanks
  