Having looked at the Factory Design Pattern in the examples directory I have a few questions as it applies to my application.
I have a text file that contains all the parameters for construction of a set of objects.
I’ve split this text file into a string() array. (Each line of the text file is an element of the string array)
I have the string array and a current line number in that array. Should this be a class of it’s own?
So what does the class hierarchy look like?
I presume all these object will share the same base class.
I have a base class called MyBaseClass and then a set of classes that inherit from it
ClassA::MyBaseClass, ClassB::MyBaseClass, ClassC::MyBaseClass.
MyBaseClass?
How do I pull one object at a time out of the factory until I’ve gotten an EOF indication?
OK, that’s clearer. My next question is, why do you have this file? Is it something you created or something you’ll obtain from elsewhere?
To answer your original question, you will need a large SELECT statement to create the objects so it makes sense to create superclass with a shared “factory” method that returns the appropriate subclass.
Without more details about what you’re doing and why, that’s the best I can do.
Way not enough information. What is the main problem that you have? If you have lots of options and hundreds of lines of code with many methods THEN ONE OO pattern makes sense. The Strategy pattern comes to mind. THEN thinking about class hierarchy makes sense.
For myself, if I keep getting confused what something is supposed to do then I think about refactoring. A couple of “if then” or some methods aren’t bad.
I’ve written a small project to explain what I’m trying to do…
I’m almost there I just don’t quite now how to construct an object in the base class. Object Factory Example
Is per the first line of this this thread:
Having looked at the Factory Design Pattern in the examples directory I have a few questions as it applies to my application.
@Brian: if you don’t understand both the example from Xojo and my code it would be better to get a more thorough understanding of patterns. The graphics at http://www.oodesign.com/factory-pattern.html tell you everything you need to know. You need an interface and not a parent class.
MyBaseClass could have a SHARED method that takes whatever text you’ve read from the file that is “one object”
Maybe call it “MakeNewInstanceFromText”
That Shared method should return a “MyBaseClass” since that is the parent of all subclasses
So it’s signature is like
MakeNewInstanceFromText( whatever text it has for creating this instance ) as MyBaseClass
Each of your subclasses could have a similar shared method
In that shared method IF myBaseClass figures out, through whatever code you write, that it needs to construct a “ClassA” then it should do something like
return ClassA.MakeNewInstanceFromText( whatever text it has for this instance )
Now there are issues with having each class hold its own factory method
In this set up the base class has to know about all the subclasses and has a dependency on them
It’s possibly better to have each class just have a constructor that takes a text representation of the data it should be created with and put all the shared methods in a single module and call those instead
That way the factory is the module & each class just knows how to create itself and not worry about dependencies on subclasses etc
Thanks all. About the Xojo example factory
I thought I could get past having the shared method to create objects.
I guess I don’t understand why the base class declares a protected constructor that does nothing and all the derived classes call Super.constructor.
a protected constructor means you HAVE to use the factory to create an instance
But, since its protected, subclasses can call it using Super.constructor and the super class constructor will do its thing
[quote=271304:@Norman Palardy]a protected constructor means you HAVE to use the factory to create an instance
But, since its protected, subclasses can call it using Super.constructor and the super class constructor will do its thing[/quote]
But in this case ‘its thing’ is nothing, but ‘could’ be something.
generally when you use a factory pattern you dont have the classes have a public constructor because you want every instance to be created through the factory
Last question I think.
The CreatePizza method is shared.
What is the significance of it being shared?
Is that just so that all instances and sub classes have the same method and it can’t be overridden?
In my case having this method available to derived classes is bad.
[quote=271309:@Brian O’Brien]Last question I think.
The CreatePizza method is shared.
What is the significance of it being shared?
Is that just so that all instances and sub classes have the same method and it can’t be overridden?
[/quote]
No
Shared has nothing to do with cant be overridden - that would be analogous to Java’s “FINAL” which Xojo doesn’t have http://developer.xojo.com/userguide/properties-methods-and-events
Shared means “the method is part of the CLASS” not just a specific instance
Normally you cannot call a method of a class without an instance - except in the case of SHARED ones
Why ?
Even if you call subclass.SharedMethod the superclass one gets runs - unless that subclass implements the same shared method