Last week, on my blog, I discussed simple and static factories briefly. That post, however; only talked about some of what factories can do. This week, to round off my knowledge, I choose to reaffirm learn more about abstract factories. The best resource I found to help me with the topic was oodesign.com (Object oriented design). Above I’ve linked all three of their pages on factories but I’ll mostly be concerning myself with the last one, abstract factories. For the most part, I can earnestly say I didn’t know much about abstract factories. I’m not the most well-read developer, yet. But immediately they seemed like an impressive tool.
From my readings and class lectures this week, I know that Factory Method pattern uses an interface to create objects while allowing for subclasses to decide the type of object. I learned though, that abstract factories were an extension of this functionality. They are essentially a factory of factories that allows us to take advantage of the “code to an interface” principle.
I can immediately recognize that abstract factories prove a good practice to code. In the pages, I saw that every subclass had their own factory classes written for them (meaning that factory method pattern and abstract factories work well together). Subclasses can be added to an interface, so long as they are compatible (in the same family of objects). This would seem to promote easier refactoring and extending functionalities of programs. And, as a developer, I assume that any program I write will need to be expanded or edited. If abstract factories truly do make it easier on that front, then I’d be more than willing to use them. Unfortunately, I do have a concern relating to their extendibility.
They aren’t entirely flexible, that is, an abstract factory can’t help creating in an object that isn’t in the same family. The added abstraction and encapsulation seems like it would start to become overly complex or cluttered for it to be easily read by humans. With every interface having multiple subclasses and factories, any UML diagram or visual would start to get cluttered or cumbersome if a program has multiple interfaces that create families of objects. Making the code more efficient and organized doesn’t mean we’re making it easier to read. We should remember that it’s humans that will edit our work after all. Though, since it seems like factories in general are prevalent, I’m sure I’ll become practiced enough that they aren’t daunting. I just don’t want to be the guy who makes someone else’s day difficult because his code is hard to read.
Using abstract factories also avoids using conditional logic, it seems. The usual factory design pattern would use if statements or switches to decide which subclass to return but, as I said before, each subclass has its own factory. The abstract factory then returns the subclass depending on the input factory class. Conditional statements aren’t necessarily difficult to write and understand. The appeal to avoiding them, to me, is avoiding certain errors all together. I have less to worry if less of my code can throw an error. Also, if the program were of a larger size, there may be a so many conditions that writing a case or if statement for everyone would become painstaking. Being able to avoid errors and making code easier to write is an attractive feature.
Just like the other factory patterns, I can see there is a place for abstract patterns in the workplace. Now I just want to be sure I know when and how to use them. I’ll certainly be practicing with them.