Factories are used to create objects. I was wondering if it's against the purpose of a factory, if I would bind couple of objects together in the factory. Let me illustrate this with an example.

Let's say I have a factory that produces modal dialogs. The factory can instantiate a view, which will display on screen. Also I need some buttons to be present on the view and which should provide some functionality, let's say call a service via some delegation.

Depending on type of the modal dialog I want to be able to provide different buttons and different behaviours.

class ModalFactory {

       static func createWeatherModal() -> ModalWindowProtocol {
           let modal = SomeModal()
           let closeButton = CloseButton() 
           let verifyWeatherButton = WeatherButton()
           let service = RemoteApi()

           verifyWeatherButton.performAction {

           closeButton.performAction {

        static func createAdvancedWeatherModal() -> ModalWindowProtocol {
           let modal = AdvancedWeatherModal()
           let service = AdvancedWeatherService()
           let weatherButton = WeatherButton()
           let closeButton = CloseButton()
           weatherButton.performAction {
           closeButton.performAction {

So, there you have it. The binding of an tap event happens in factory. Is this a good practice? And if not, then what would you suggest for this kind of dynamic modal creation and binding?

Thank you

  • Is this TypeScript? The language and platform might make a difference here, as well as the framework in use. – Greg Burghardt Aug 28 '18 at 14:46
  • That's swift. I don't use any framework apart from standard library, at least not for this part of code. – DS888 Aug 29 '18 at 7:12

While the caller requires no direct input on how to create the object being produced by the Factory, a Factory pattern is perfectly fine, even when you're producing multiple objects.

If you want to be more dynamic and allow flexibility in creation, without giving up the advantage of leaving it to the class to deal with the specific implementations, consider using a Builder pattern.

The example they use is a CarBuilder which lets you build a Car by specifying various aspects of that car. If you think you can make both a "weather modal" and an "advanced weather modal" using this class, then great! Builder pattern is for you! If not, don't force the class to handle both. Create a second builder as necessary in that case.


If it's good enough for Bill Gates...


However, it's not very MVVM. You don't say what language or framework you are using, but I think if you did all your controls like this you would end up with a lot of view logic in the factory class, which depending on your framework might not be best practice

  • Yes, exactly. I wanted to avoid having to put the logic into the factory. With Neil's suggestion, I think I would be able to provide dynamic behaviour to the modals by providing concrete delegate implementations. – DS888 Aug 29 '18 at 7:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.