4 ms·

Uh yes, probably a factory is never going to be an optimal solution. Never? That seems a little extreme, no? It's a tool like any other and IMO, it's a sometim

Uh yes, probably a factory is never going to be an optimal solution. Never? That seems a little extreme, no? It's a tool like any other and IMO, it's a sometimes useful idiom that works pretty much identically in Go as it does in other imperative languages. However, I'd be interested in any links you could provide which might elaborate on why a factory is never an optimal solution. If you know what type you need, why would you need a factory to create it for you? Just create it. I already explained why. The Factory abstracts away instantiation and configuration details for a complex or dynamic initialization process. I understand you don't agree with that approach, but it's fairly common. (see page 5) http://www.cs.colorado.edu/~kena/classes/6448/f07/lectures/21/21-Factory.pdf#page5 http://www.cs.colorado.edu/~kena/classes/6448/f07/lectures/2... (see accept answer) http://programmers.stackexchange.com/questions/81838/what-is-the-difference-between-the-factory-pattern-and-abstract-factory http://programmers.stackexchange.com/questions/81838/what-is... but there's pretty much never a reason to have a function create a variety of types for you. The capability to define a function's return type to as an interface type would suggest otherwise, but we'll have to agree to disagree in that regard. :)

NateDad 12y ago
The Factory abstracts away instantiation and configuration details for a complex or dynamic initialization process. Is there some reason you can't do that by just having this? func IntializeFoo(f *foo) The capability to define a function's return type to as an interface type would suggest otherwise Uh... if you know what type the function is returning you, why do you need it to return an interface? You don't need the interface until you pass it into a function that requires an interface, at which time, the type you've made will be converted for you... why convert before you need to? Either the consumer should never need to know about types, in which case, you should probably just make it an enum: type ServiceType int const ( Weather ServiceType = iota News ServiceType ) type Service interface {} func Service(type ServiceType) Service Or if the consumer should know about the service types for some reason, you can use the Initialize method above... or to genericize it better, and remove any need for the factory to know about concrete types: func Initialize(svc Service) If you can avoid having both sides know about concrete types, it'll make your life a lot easier.

NateDad 12y ago

The Factory abstracts away instantiation and configuration details for a complex or dynamic initialization process. Is there some reason you can't do that by just having this? func IntializeFoo(f *foo) The capability to define a function's return type to as an interface type would suggest otherwise Uh... if you know what type the function is returning you, why do you need it to return an interface? You don't need the interface until you pass it into a function that requires an interface, at which time, the type you've made will be converted for you... why convert before you need to? Either the consumer should never need to know about types, in which case, you should probably just make it an enum: type ServiceType int const ( Weather ServiceType = iota News ServiceType ) type Service interface {} func Service(type ServiceType) Service Or if the consumer should know about the service types for some reason, you can use the Initialize method above... or to genericize it better, and remove any need for the factory to know about concrete types: func Initialize(svc Service) If you can avoid having both sides know about concrete types, it'll make your life a lot easier.