Reputation: 11
Does the Factory Method only follow the Dependency inversion principle and interface segregation principle in the SOLID? I found that on another website but couldn't really find any arguments why it implement the interface segregation principle. It follow DIP because it depend on an interface(abstraction) and not concrete classes.
Upvotes: 1
Views: 3397
Reputation: 261
You cannot confirm that the Factory Method pattern will follow the Interface Segregation Principle per se, without the rest of the interfaces. That principle means essentially that a class will most likely use the whole interface of another class, so the factories would probably follow this principle if they only provide a method or two to construct the instances to be used by the client (this comes tightly related to the Single Responsibility Principle in this case). However, that doesn't mean the Client will follow that principle.
As for the Dependency Inversion Principle, it's easy to identify if you compare the design with and without this pattern. Without the FM pattern, your client has to decide which subtype of a constructable object to instantiate and use. Thus, these would be the dependencies (separate components delimited by parenthesis; arrow direction means "depends on"):
(Client) -+-> (ConstructableA)
\-> (ConstructableB)
When you apply the Factory Method design pattern, the dependencies between components are:
(Client -> IConstructable) <-+- (ConstructableA)
\- (ConstructableB)
So, effectively, the dependencies between components are now inverted. In the former case, the Client component had to change (likely) whenever either constructable component changed. In the later, the Client component can be reused in other places, and the Constructable* components have to change whenever IConstructable does.
Upvotes: 0
Reputation: 8541
Firstly factory method is a standalone design pattern to create objects without exposing the instantiation logic to the client. The factory method doesn't follow any principle but it is meant to separate the responsibility of object creation to a different class to deal with the problem of creating objects without having to specify the exact class of the object that will be created. As it is a creation pattern it's responsibility is just creation of the object. It has nothing to do with interface segregation principle as well. Interface segregation principle is mainly focusing on not creating fat interfaces but make it lean and group in logically in such a way that no client should be forced to implement the method it doesn't require.
Please don't get confused with SOLID principles and design pattern. SOLID principles are just a set of principles to achieve clean code. Few design pattern helps to achieve SOLID principles. For example, you move the responsibility of object creation to a factory, then factory's whole responsibility would be object creation (single responsibility principles) and so on.
Upvotes: 2