Of course not.

The factory pattern is useful if you need to encapsulate create-time polymorphism from consumers, that is, you want to provide a transparent point from which new instances of a polymorphic type are created.

If the type in question is not polymorphic, the factory pattern is pointless.

If a single point of creation doesn’t make sense, neither does the factory pattern.

If it is undesirable to hide the polymorphism details away, the factory pattern is probably inappropriate, too.

As with anything that adds complexity, you should default to not using it, but spot the point at which it is beneficial early on and apply it before it is too late.

Also, consider this: If you use a factory for everything, who creates the factory? Another factory? And who creates that?

I don’t know a lot of people using design patterns in PHP, but Joshua Bloch recommends the Factory pattern in his book, “Effective Java.” In fact, it is his first recommendation: Item 1. Here are several of his points which are specific to Java, but most probably apply to PHP:

Advantages

• As you mentioned, a factory method can return any sub-type of object
• Unlike constructors, factory methods are not required to create a new object each time they are invoked – this allows you to manage the set of objects internally. For example, a printable ASCII character class only ever needs 95 instances. You don’t need two objects to represent a lower-case ‘k’.
• Factory methods can be given meaningful names (in Java)

Disadvantages

• In Java, you cannot create a subclass if the parent class lacks a public or protected constructor.
• Static factory methods are not readily distinguishable from other static methods. Bloch suggests a naming pattern to distinguish them.

The goal behind most of Bloch’s suggestions is that if you send your class out into the world and many people use it, you want it to present an interface that allows you to adapt and change the implementation of your classes without breaking client code. Bloch’s perspective was formed by trying to fix bugs and design flaws in the Java API’s without changing the interface that they present to the world.

Create an static Factory class.

That class will have static methods like this:

public static class Factory{

    public static Vehicle getCarInstance(){ ... }
    public static Vehicle getPlaneInstance(){ ... }
    public static Vehicle getVehicleInstance(int TYPE){ ... }

    public static Vehicle getVehicleWithPlaqueNumber(String plaqueNo){...}

    public static Account getAccountByID(int ID){..}

}

You don’t need a Factory for every class.

Your question is not answerable.

“Factory” is simply too vague to be called a pattern.

If you read in GoF Design Pattern book, there is no such thing as “Factory” pattern.

Instead, there are several kinds of factory, which are Factory Method, and Abstract Factory. Different kind of factory is solving different problem. You should know what what problem you are trying to solve, before you decide you want to adopt a pattern.

So, tell us, what problem you want to solve?