3 ms·

I was in a rush and didn't create the most illustrative example. you already know which provider you want to use, so why not just initialize the struct from th

I was in a rush and didn't create the most illustrative example. you already know which provider you want to use, so why not just initialize the struct from there and skip the factory method altogether. The reason that I want ProviderFactory to generate instances is because I also want it to act as a manager for those instances. ProviderFactory can keep track of all ServiceProviders and perform various operations or broker data between instances. Here is my previous example slightly improved. http://play.golang.org/p/XoXu9x9r8f http://play.golang.org/p/XoXu9x9r8f Now, ProviderFactory injects configuration information into ServiceProvider instances based on their concrete type, before establishing a connection. A more complicated app might wrap the NewProvider function into a gorotune/callback that blocks each provider instantiation until a successful connection has been established. This is all beside the point though; all I want is something akin to a special "type" type that the compiler recognizes as a symbol for that type that the factory can use to evaluate which concrete type to produce.

rakoo 12y ago
You're still leaning too much in types. Go is a very lightweight type system. The setter and base type basically scream for "I want to use my Java in Go". I'm not even talking about using a factory. Here's I would do it: http://play.golang.org/p/EmxCRkDNLC http://play.golang.org/p/EmxCRkDNLC
NateDad 12y ago
Your code seems incredibly backward. Why does the ProviderFactory hold the knowledge about the query interval for each provider? Shouldn't the provider hold that information? With the data structure you have, any time you add a new provider, you'd need to add a new case to that switch statement. That's like the polar opposite of separation of concerns. Let the query interval be defined on the type, not in the factory. The same for the host they connect to. Shouldn't that be defined in the type? Like make WeatherProvider.Connect() call ProviderFactory.WeatherHost() to get the host to connect to. You're doing everything inside out. What do the types even do in your example? This isn't a Go problem, it's programmer problem.
- vectorpush 12y ago
  This isn't a Go problem, it's programmer problem. Thanks, but just to be clear, this is not a sample from a real application, it's just a contrived demo designed to illustrate the pattern. Why does the ProviderFactory hold the knowledge about the query interval for each provider?...Let the query interval be defined on the type, not in the factory. As previously stated, the example is contrived. If this were a real application it could probably make sense to define the query interval on the specific type, but lets just say, for the sake of illustrating the idea, that the desired interval for a specific provider could depend not only on the type but also the total number of providers already allocated for a given type. For example, perhaps the ProviderFactory might calculate the total number of WeatherProviders already defined, and reset the query_interval for all WeatherProviders to be (some_weather_provider_specific_constant * total_number_of_allocated_weather_providers). Whenever a new WeatherProvider is requested from the factory, the factory increases the query_interval for all WeatherProviders. In this way, the ProviderFactory acts as an automatic rate limiter for each provider by keeping track of each instance. With the data structure you have, any time you add a new provider, you'd need to add a new case to that switch statement. Well yeah, that's pretty critical to the "factory" role of the ProviderFactory, how else could the factory return a variety of types if it didn't have a case/branch for each signal that represents each type? Additionally, if individual logic is required for preparing a certain type of provider, the switch statement is there to accommodate the needs of the specific type before returning it. That's like the polar opposite of separation of concerns. How do you figure? In this example, the factory is concerned with all logic related to instantiating and appropriately configuring each instance depending on the type of instance, the state of the app or the state of other instances. I'm not sure what concerns are mixed here. Alternatively, I could export all that logic into a NewFooProvider function for each of the various FooProviders, but the idea is to encapsulate all that custodial work within the factory so that a Provider user only has to request their specific provider and that's it. What do the types even do in your example? Nothing. It's just an example. The same for the host they connect to. Shouldn't that be defined in the type? Like make WeatherProvider.Connect() call ProviderFactory.WeatherHost() to get the host to connect to. I think you're missing the point. Yes, yes, that design would work fine, but all you're really telling me here is "you don't need to use a factory in this example". What I'm saying is, when I want to use a factory (lets just assume that it makes sense in the design of my app, unless your argument is that a factory is never useful), I have to indicate which type of instance I want the factory to produce by using a zeroed struct or an arbitrary data type, what's going on within my factory is actually irreverent; any example factory snippet could be refactored into something less complex when your only context is 100 lines in a scratch pad. You're doing everything inside out. I'll seriously take that opinion into consideration.
deleted 12y ago
[deleted]

rakoo 12y ago

You're still leaning too much in types. Go is a very lightweight type system. The setter and base type basically scream for "I want to use my Java in Go". I'm not even talking about using a factory. Here's I would do it: http://play.golang.org/p/EmxCRkDNLC http://play.golang.org/p/EmxCRkDNLC

NateDad 12y ago

Your code seems incredibly backward. Why does the ProviderFactory hold the knowledge about the query interval for each provider? Shouldn't the provider hold that information? With the data structure you have, any time you add a new provider, you'd need to add a new case to that switch statement. That's like the polar opposite of separation of concerns. Let the query interval be defined on the type, not in the factory. The same for the host they connect to. Shouldn't that be defined in the type? Like make WeatherProvider.Connect() call ProviderFactory.WeatherHost() to get the host to connect to. You're doing everything inside out. What do the types even do in your example? This isn't a Go problem, it's programmer problem.

vectorpush 12y ago
This isn't a Go problem, it's programmer problem. Thanks, but just to be clear, this is not a sample from a real application, it's just a contrived demo designed to illustrate the pattern. Why does the ProviderFactory hold the knowledge about the query interval for each provider?...Let the query interval be defined on the type, not in the factory. As previously stated, the example is contrived. If this were a real application it could probably make sense to define the query interval on the specific type, but lets just say, for the sake of illustrating the idea, that the desired interval for a specific provider could depend not only on the type but also the total number of providers already allocated for a given type. For example, perhaps the ProviderFactory might calculate the total number of WeatherProviders already defined, and reset the query_interval for all WeatherProviders to be (some_weather_provider_specific_constant * total_number_of_allocated_weather_providers). Whenever a new WeatherProvider is requested from the factory, the factory increases the query_interval for all WeatherProviders. In this way, the ProviderFactory acts as an automatic rate limiter for each provider by keeping track of each instance. With the data structure you have, any time you add a new provider, you'd need to add a new case to that switch statement. Well yeah, that's pretty critical to the "factory" role of the ProviderFactory, how else could the factory return a variety of types if it didn't have a case/branch for each signal that represents each type? Additionally, if individual logic is required for preparing a certain type of provider, the switch statement is there to accommodate the needs of the specific type before returning it. That's like the polar opposite of separation of concerns. How do you figure? In this example, the factory is concerned with all logic related to instantiating and appropriately configuring each instance depending on the type of instance, the state of the app or the state of other instances. I'm not sure what concerns are mixed here. Alternatively, I could export all that logic into a NewFooProvider function for each of the various FooProviders, but the idea is to encapsulate all that custodial work within the factory so that a Provider user only has to request their specific provider and that's it. What do the types even do in your example? Nothing. It's just an example. The same for the host they connect to. Shouldn't that be defined in the type? Like make WeatherProvider.Connect() call ProviderFactory.WeatherHost() to get the host to connect to. I think you're missing the point. Yes, yes, that design would work fine, but all you're really telling me here is "you don't need to use a factory in this example". What I'm saying is, when I want to use a factory (lets just assume that it makes sense in the design of my app, unless your argument is that a factory is never useful), I have to indicate which type of instance I want the factory to produce by using a zeroed struct or an arbitrary data type, what's going on within my factory is actually irreverent; any example factory snippet could be refactored into something less complex when your only context is 100 lines in a scratch pad. You're doing everything inside out. I'll seriously take that opinion into consideration.

deleted 12y ago

[deleted]