Ask yourself what they are and why do we have them. They both are there to create instance of an object.
ElementarySchool school = new ElementarySchool();
ElementarySchool school = SchoolFactory.Construct(); // new ElementarySchool() inside
No difference so far. Now imagine that we have various school types and we want to switch from using ElementarySchool to HighSchool (which is derived from an ElementarySchool or implements the same interface ISchool as the ElementarySchool). The code change would be:
HighSchool school = new HighSchool();
HighSchool school = SchoolFactory.Construct(); // new HighSchool() inside
In case of an interface we would have:
ISchool school = new HighSchool();
ISchool school = SchoolFactory.Construct(); // new HighSchool() inside
Now if you have this code in multiple places you can see that using factory method might be pretty cheap because once you change the factory method you are done (if we use the second example with interfaces).
And this is the main difference and advantage. When you start dealing with a complex class hierarchies and you want to dynamically create an instance of a class from such a hierarchy you get the following code. Factory methods might then take a parameter that tells the method what concrete instance to instantiate. Let’s say you have a MyStudent class and you need to instantiate corresponding ISchool object so that your student is a member of that school.
ISchool school = SchoolFactory.ConstructForStudent(myStudent);
Now you have one place in your app that contains business logic that determines what ISchool object to instantiate for different IStudent objects.
So – for simple classes (value objects, etc.) constructor is just fine (you don’t want to overengineer your application) but for complex class hierarchies factory method is a preferred way.
This way you follow the first design principle from the gang of four book “Program to an interface, not an implementation”.