Menu
I've been becoming more familiar with the Factory Pattern (along with Strategy Pattern) and what a great benefit the pattern can have. However, I've been struggling with the following situation:
Previously, I would have done something like the following, where there's a manager class that would build and save a Car. There's no dependency injection here and is a poor implementation, especially when trying to unit test.
public class CarManager
{
public static Car GetCarFromDatabase(int carId) { return new Car(); }
public static void SaveCar(Car car) { }
}
I see now how I could have different Factories that build cars for me, whether it be from a database, or wherever! This is great! So, here's my questions:
Q1: It's my understanding that Factories should only build objects, is that correct? If so, what about my second question?
Q2: If I'm following the Factory Pattern for building my objects, how should I go about saving my objects? Is there a different pattern for this, or am I not completely understanding the Factory Pattern?
987
Factory Method Pattern allows the sub-classes to choose the type of objects to create. It promotes the loose-coupling by eliminating the need to bind application-specific classes into the code.
Factory Design Pattern Advantages Factory pattern removes the instantiation of actual implementation classes from client code. Factory pattern makes our code more robust, less coupled and easy to extend. For example, we can easily change PC class implementation because client program is unaware of this.
Here are two additional consequences of the Factory Method pattern: Provides hooks for subclasses. Creating objects inside a class with a factory method is always more flexible than creating an object directly. Factory Method gives subclasses a hook for providing an extended version of an object.
A Factory Pattern or Factory Method Pattern says that just define an interface or abstract class for creating an object but let the subclasses decide which class to instantiate. In other words, subclasses are responsible to create the instance of the class.
The factory pattern aims to solve a fundamental problem in instantiation – i.e., the creation of a concrete object of a class – in object-oriented programming. In principle, creating an object directly within the class that needs or should use this object is possible, but very inflexible.
The Factory pattern is supposed to help with the creation of objects. That is why it is categorized as a "Creation" pattern. To answer your first question, it should not be used to persist objects.
The Repository pattern is a persistence pattern that should be used for saving objects to some persistence mechanism or retrieving data from a persistence mechanism. This is actually, according to Martin Fowler, an enterprise pattern which should be approached different than the typical design pattern.
When thinking about your question, you want to look at the S principle in SOLID which states that a class should have a single responsibility, which means that it should have a single reason to change. In this case, when talking about a object that creates objects as well as saves (persists) them, you have a class that has two reasons to change. Now, it might look like it could be a single responsibility because a Repository can retrieve and save objects into your application and the retrieve can look like a factory (and often is a factory object within the repository), but in what you're describing, your object has one too many responsibilities.
137
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
