Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 3 of 3
03-05-2014, 10:03 PM #1
- Join Date
- Mar 2014
- Thanked 0 Times in 0 Posts
PHP include file within class - scope
I'm writing a basic framework (for small 4-5 page sites, no need for Cake, Smarty etc).
I understand that when I have a method within a class which calls a file include, the scope of that included file stays within the class's method it was included in.
However, I have a few different classes for the framework, and want to allow data to be used from the other classes within the included template file, but this scope issue stops me doing so without, what seems, a muddy approach.
1) MetaClass: To set Header & Meta data (Doctype; page title; description; etc class checks data and allows objects to be used in the template file);
2) StyleClass: To set stylesheets required (class returns an array looped in the template file outputting meta style tag for each one);
3) TemplateClass: To call template files, such as header, nav, body, footer, etc;
4) Some other classes;
From what I've read, the general approach is to send into the TemplateClass (the one which includes the template files) variables of all the other class data.
But, this way, I'm stuffing all data from all my classes (eg MetaClass, StyleClass, etc) through one class, the TemplateClass, just because the scope of the included template files lies within that one class.
Surely there is a better way than this? I'm happy to restructure the framework approach I have if needed, i.e. rather than solve this issue with the structure I have.
Problem is if another class was to be introduced, or one or all the current classes were to be changed in some way, it could easily cause an issue with the variables/data being passed into the TemplateClass, and thus a problem within the template file (or fatal error before that).
e.g. I change MetaClass to also allow keywords to be defined, I now have to add these variables/array keys to the TemplateClass, and consider if/how they're handled within the TemplateClass.
OOP was designed to allow for classes to work independently, or be extended to each other whenever appropriate, and this way it just seems like I'm creating a bottleneck where all classes have to "obey" to a single class.
Any advice greatly welcomed.
03-05-2014, 10:54 PM #2
- Join Date
- Sep 2002
- Saskatoon, Saskatchewan
- Thanked 2,660 Times in 2,629 Posts
Includes will always take the scope of call either procedurally or object oriented.
OOP isn't designed to work just independently. Its designed to have objects represent pieces of a whole and by doing so it allows you to work independently on a part without needing to overhaul the whole and works especially well with interfacing (which is at least 100x more useful in single inheritance languages than extends is and weighs well to decoupled objects too). Same as a mechanic can perform work on a single component in a vehicle without having to dismantle the entire vehicle. For a simple example I could have a class called User which represents a client object, and this User class has a collection of type UserProfileField. The UserProfileField object represents a field and value pair for their profile, such as their birthday or hobbies. That's still a class composed of a collection of other classes. This in particular aggregates the data together, so I can have both independent, but the UserProfileField has no value without the owning User object.
There are dozen and a half ways to perform class interaction. The easiest is simple composition where you supply one object with another during construction so that they work together. There is nothing wrong with binding pieces that belong together. Where runtime class choices are concerned, you would use interfaces to enforce the rules (this is especially useful in PHP due to its loose nature).
If TemplateClass logic works to handle everything as a central hub, then there's no need to feel to not use it as such. If it doesn't suit as the single point, modify to work around it either directly within the class or as an adapter class and wrap the two pieces together. Typehinting in PHP is key to proper design process just like any other OO language. I don't care if the class is called AClassThatDoesThis or NotAClass, if I were to typehint an object of interface type MyInterface, than all I care about is that its of type MyInterface and the runtime class doesn't matter.
For a much simpler example, say you have a Configuration class. This class' entire job is to draw configuration data in, and store it for requests in whatever fashion you see fit. Now say you collect all components together in a class called Framework either composed of type Configuration or directly instantiates Configuration. This has the job of accepting input from the user, and determining which component(s) it needs to handle the request, establishes the components and sends them on their way for processing. What you could do for a composition approach is simply have all these components accept a parameter in the constructor of type Framework. The framework would have a method, perhaps one interfaced from the Configuration class if it were interfaced, which simply allows it to provide configurations on request. Again, there are a dozen and a half ways to communicate this information between the objects.
A singleton anti-pattern could also be used to ask the configuration object to statically create itself. It simply shares the same object with anything that asks. Personally I don't like the singleton and would suggest dependency injection as the better alternative.
header('HTTP/1.1 420 Enhance Your Calm');
Users who have thanked Fou-Lu for this post:
03-05-2014, 11:10 PM #3
- Join Date
- Mar 2014
- Thanked 0 Times in 0 Posts
Thank you, for such a detailed response!
In retrospect, it was a bad choice using the word "independently" to describe the opposite of my situation. I just meant I didn't think it's a good design for all my classes to be bottlenecked through one single class.
Having read what you've put, however, I suppose the pro to this as is a single class being "responsible" for the templates and scope of the data used within them, ensures everything is loaded as should be.
I'll need to re-read your reply tomorrow when not so tired, as I'm not a seasoned OOPer and with the reading of so much OOP and MVC concepts recently, it's all taking some time to piece together in my mind to understand the greater picture, and in a best practice manner.