为什么不进行工厂模式排序？ [关闭]

At run time, based on user behavior and history, I need to perform a sorting operation. In my case, SortByDate/SortByDemand/SortByConsumption will just return the string, or we can say order by clause(which can be complex).

In most of the forums, I have found Strategy pattern should be used for sorting.

I have attached the image for Strategy pattern here. Util class will call the object of one the three classes i.e SortByDate/SortByDemand/SortByConsumption

So every time a new method of sorting is defined, I need to change the util class and define a new Strategy.

If however I implemented it using factory, the util class just need to call the factory and it will take care of which class to call. So I think I should use factory.

However I have read that strategy is best pattern for such needs. Why is strategy pattern is better here?

Strategy is a pattern aimed at allowing you to add new (in your case sort) algorithms to your software without breaking the clients of the algorithms. It's an investment in design complexity that will pay off if you need to add new algorithms without breaking your clients. Factory is a pattern that complements Strategy because the clients of the algorithm implementations should not know specifically which implementation they're using (in terms of software classes). The factory instantiates the concrete implementations of the algorithm so the client can use them without knowing the details.

Here's the static structure:

Here's the dynamic:

What you have done is not a factory pattern, but a mix of both, which is not clear and, in my opinion, wrong.

In the second example, the class names are wrong and confusing. SortByDateFactory does not behave like a factory (it does not produce anything) but it does behave like a strategy. Therefore, it should comply to a strategy interface.

On the other hand, in the first example, the UtilClass behaves like the factory you want to make. So, I would suggest to keep the first example as is, but rename the UtilClass to SortStrategyFactory.

Both of those diagrams look like the strategy pattern, but with the bottom one bodged a bit. If you want a factory, it means that utilclass will be abstract and have a factory method, which instantiates a sorter class. The specific type of sorter defined by the specific subclass of utilclass.

The point of the strategy pattern is to avoid being tied into a class hierarchy so you can mix and match the various sorters with various other features. The factory is appropriate when you are using subclasses of utilclass and a particular subclass (with all the rest it's functionality) will always want a particular sorter and never a different one. Choose the right one based on your needs.

You're effectively using both factory and strategy. The factory decides which strategy to create; the strategy carries out the sorting logic.

Your bottom diagram is confusing because you inherit your strategies from your factory. The factory should just create the right strategy.

The client just asks the factory for the strategy and uses it.