OOP - Recommended Template/Theme/Page Design Structure

[Bladescope]

Hey PHPFreaks!

 

I'm designing an online application using OOP. This is by no means my first application, but it is using Object Oriented techniques, so I come to you helpful folks with a question.Essentially, I would like to be able to find out about recommended ways to approach page templates in a class design, as well as other general good class design practices specific to  server-side languages.

 

So, without further ado, what is considered a good/recommended method of approaching template design using OOP? For example, a base template class which can be extended for multiple themes, so additional themes don't have to recreate the core functionality if they decide not to change it. It seems that there are a lot of methods to approach it, which is why I'm here!

 

Any help you can provide would be greatly appreciated!

[trq]

Your markup should be completely separate to your business logic.

[Bladescope]

Your markup should be completely separate to your business logic.

 

Would you care to clarify? I'm rather confused.

[trq]

Your markup (html, css etc etc) should be as far removed from PHP as possible.

[creata.physics]

If your going to use object oriented programming I'd take a look at the singleton pattern.

http://www.oodesign.com/singleton-pattern.html

 

Just because you have a class with functions and call the class and use your functions doesn't mean your code is object oriented. It means you use objects, the singleton pattern is object oriented and is a great method and learning experience.

 

I agree with what Thorpe stated, definitely keep your php code separate from html and css.  Also, the link I provided you with is a great resoure for learning oop designs and oop in general. Spend some time reading there.

 

Didn't know php had a Patterns page, take a look here for the php side of the singleton pattern

http://php.net/manual/en/language.oop5.patterns.php

[trq]

Just because you have a class with functions and call the class and use your functions doesn't mean your code is object oriented. It means you use objects, the singleton pattern is object oriented and is a great method and learning experience.

 

Sorry, but this statement is absolute BS. A singleton is one of many design patterns. Just because you start using singletons does not mean your code is well designed OOP. In fact the singleton is also one of the patterns that should be avoided as much as possible as it can break encapsulation if not used properly.

[cpd]

If your going to use object oriented programming I'd take a look at the singleton pattern.

http://www.oodesign.com/singleton-pattern.html

 

Just because you have a class with functions and call the class and use your functions doesn't mean your code is object oriented. It means you use objects, the singleton pattern is object oriented and is a great method and learning experience.

 

I agree with what Thorpe stated, definitely keep your php code separate from html and css.  Also, the link I provided you with is a great resoure for learning oop designs and oop in general. Spend some time reading there.

 

Didn't know php had a Patterns page, take a look here for the php side of the singleton pattern

http://php.net/manual/en/language.oop5.patterns.php

 

Having previously read this page over the years I'd like to draw your attention to the tip slightly further down the page after loading. It explains why the Singleton Pattern concept is not ideal for PHP OOP. Instead, you should create individuality with your objects as detailed by the Law of Demeter, also mentioned in the tip.

 

I personally love the MVC method of programming. It fits perfectly with my page execution concept (Y). Whilst its not specifically object oriented, it's still very nice and can be used in object-oriented languages very easily; therefore allowing you to use it in an object-oriented fashion.

[cpd]

@creata.physics - Apologies if you think that was a second dig at you. Thorpe and myself posted at the same time; never realised he was posting.

[creata.physics]

@Thorpe - What part is bs? The singleton pattern is a great learning experience (opinion) and is object oriented (fact). I just don't understand.

[trq]

As I pointed out, the singleton is a particularly evil pattern and should be used sparingly. Recommend someone learn it and stating "it is OOP" is misleading at worst.

 

These days, the singleton is considered somewhat of an anti-pattern because of it's blatant misuse.

 

The singleton pattern is a great learning experience (opinion)

 

It's also probably the simplest pattern around so I don;t see how it's a "great learning experience".

[creata.physics]

If you don't see how simplicity is great then I don't know what else to say to you.  I just felt attacked and like you were trying to make me feel stupid. It seems you have a personal issue with the singleton pattern or people who recommend it and you need to leave that crap behind the screen. My statement is not BS, and you know it. You were just being difficult.

[trq]

Whatever, this thread has been dragged way off topic as far as I can see.

 

It seems you have a personal issue with the singleton pattern or people who recommend it

 

Why would I have a "personal issue" with a design pattern? I have issue with it's misuse.

[cpd]

Creata, I feel your using my previous post, the apology, as an excuse to start an argument. I don't see any personal insults but can see why you may feel there are some.

 

As I explained, the singleton pattern isn't ideal for php. Thorpe said the same thing in his/her own way. Don't make an assumption on thorpe's tone, that's the worst thing you can do on a forum.

 

On a side note, simplicity is good but as mentioned, it can sometimes be misconstrued as has been done here with the singleton pattern.

[Muddy_Funster]

If you don't see how simplicity is great then I don't know what else to say to you.  I just felt attacked and like you were trying to make me feel stupid. It seems you have a personal issue with the singleton pattern or people who recommend it and you need to leave that crap behind the screen. My statement is not BS, and you know it. You were just being difficult.

Whoa there creata .  That's a bit over dramatic.  thorp is as entitled to his opinion as you are yours.  surely you knew suggesting something as controversial as the singleton pattern as a first point of learning for OOP design was going to stir up some comments against it?  there is nothing posted against you as an idividual, only the content of your post, which is fair game on any forum.

 

the appreciation of simplicity is a contextual thing, if simple is what you want then its great, if it's not then it's not.  At the end of the day you are (were) both trying to help the OP in your own way, you should never let yourself get persoanly attached to things that are put on the internet IMO it's not worth the pain.  What I think would be best would be to expand on your arguments, such as pointing out (calmly ) that as long as you are aware that it is not best practice it's still a good thing to be aware of and a valid learning resource.

[Drongo_III]

Erm stepping around the feud above. You might want to read up a bit on the concepts behind MVC. This will set you on the right path for understanding how to separate your themes from you 'business logic' .

 

Before anyone decides to level their cannons at me this is just a suggestion *ducks for cover*

[cpd]

Erm stepping around the feud above. You might want to read up a bit on the convepts behind MVC. This will set you on the right path for understanding how to separate your themes from you 'business logic' .

 

Before anyone decides to level their cannons at me this is just a suggestion *ducks for cover*

 

Words of f***ing wisdom! Thank you for reinforcing my original comments! Love MVC

[Drongo_III]

haha i have my moments...few and far between as they are...

 

Erm stepping around the feud above. You might want to read up a bit on the convepts behind MVC. This will set you on the right path for understanding how to separate your themes from you 'business logic' .

 

Before anyone decides to level their cannons at me this is just a suggestion *ducks for cover*

 

Words of f***ing wisdom! Thank you for reinforcing my original comments! Love MVC

[scootstah]

I just wanted to point out that while MVC is a great pattern, keep in mind that you can deviate from it a bit. For small applications, strict MVC may be a little overkill. Often times for small stuff, I'll knock out the Model portion of MVC and just use my Controllers for everything, while still being able to easily break business from presentation.

 

If you don't see how simplicity is great then I don't know what else to say to you.

 

If you don't see the problem with Singletons and how they can be misused then you should stop right there and go read up on it. Most of the time, Singletons are as bad as globals. They break encapsulation and make it nearly impossible to unit test.

 

 

[cpd]

I just wanted to point out that while MVC is a great pattern, keep in mind that you can deviate from it a bit. For small applications, strict MVC may be a little overkill. Often times for small stuff, I'll knock out the Model portion of MVC and just use my Controllers for everything, while still being able to easily break business from presentation.

 

If you don't see how simplicity is great then I don't know what else to say to you.

 

If you don't see the problem with Singletons and how they can be misused then you should stop right there and go read up on it. Most of the time, Singletons are as bad as globals. They break encapsulation and make it nearly impossible to unit test.

 

Whilst I agree it can be over complicated for some jobs I would not remove the model. I only say this because of experience. By removing the model you are no longer object oriented and you require the controller which does a load of template stuff you don't need. It defeats the purpose. Arguably its dependant on how our using the MVC concept but the point still stands.

 

For simpler jobs I would look into an entirely different method which better suits my requirements.

[scootstah]

I just wanted to point out that while MVC is a great pattern, keep in mind that you can deviate from it a bit. For small applications, strict MVC may be a little overkill. Often times for small stuff, I'll knock out the Model portion of MVC and just use my Controllers for everything, while still being able to easily break business from presentation.

 

If you don't see how simplicity is great then I don't know what else to say to you.

 

If you don't see the problem with Singletons and how they can be misused then you should stop right there and go read up on it. Most of the time, Singletons are as bad as globals. They break encapsulation and make it nearly impossible to unit test.

 

Whilst I agree it can be over complicated for some jobs I would not remove the model. I only say this because of experience. By removing the model you are no longer object oriented and you require the controller which does a load of template stuff you don't need. It defeats the purpose. Arguably its dependant on how our using the MVC concept but the point still stands.

 

For simpler jobs I would look into an entirely different method which better suits my requirements.

 

Using MVC doesn't determine if something is object oriented or not. Removing Models is still object oriented, it is just a more simple pattern.

 

What do you mean the controller is doing loads of template stuff? I have a template library, template calls are one line.

[KevinM1]

MVC is a design pattern.  Tweaking it (removing models) is allowed.  Remember: design patterns are purposely half-baked in order to be manipulated to fit the realities of the actual problem in front of you.  Slavishly adhering to the textbook definition of patterns is doing it wrong.

 

On Singletons, they're global, which means by their nature they break encapsulation.  Usually, when people recommend using a Singleton, it's because they don't know about Dependency Injection, which is by far the better way to go.  Newbies like the Singleton pattern because it's incredibly simple to understand, has a neat 'hook' (using a static method and making the constructor private), and is generally the first pattern they encounter.  Unfortunately, they're almost always the wrong way to go, and learning it first teaches essentially the same bad lesson as the actual 'global' keyword.

 

On separating presentation from business/domain logic: that's the goal regardless of whether or not you're using OOP.  Your presentation layer - HTML, CSS, JavaScript - should be treated as a skin you place over the actual system.  There should hardly be any PHP code in your templates.  A good rule of thumb is to limit the PHP in a template to just echo, if/else, and loops, and, even then, only for when you're actually displaying values.  All code that 'does stuff' (like, say, queries a DB) should exist elsewhere.

[cpd]

What do you mean the controller is doing loads of template stuff? I have a template library, template calls are one line.

 

I'm not referring to whether or not using MVC determines OOP; I realise I said quite literally a model defines OOP in MVC which was wrong and is not what I was getting at so I apologise for that. What I meant was, the model is there to access the data without it being passed thrgh the controller which does a load of other stuff. It's completely dependent on your design concept though so taking it out isnt wrong, it's an idea and ideas can't be wrong .

[Bladescope]

Whoa, thanks for the topic attention O.o.

 

I think the general method I've been taught is to create a page/template class, and to use that object to take the raw template data and insert the data in that way. I've usually used something like str_replace for that.

 

As for the singleton pattern, I've been using the singleton pattern for one class only, which is my main control class to save passing the object through to each object who needs to use it. I don't particulaly know if it's the best option, most likely isn't, but I haven't been taught otherwise. I am aware that using the singleton pattern breaks encapsulation, and that it probably would actually be better to go with the other method mentioned in my post, so I may change that around now. In the meantime, I'll continue reading about the theory behind OOP which you kind folks have provided.

 

Once again, thanks for the feedback. I'm still here!

 

Edit: As for the law of demeter, I assumed that was the standard way to approach OOP, so I've been using that logic from the start. (:

[KevinM1]

As for the singleton pattern, I've been using the singleton pattern for one class only, which is my main control class to save passing the object through to each object who needs to use it. I don't particulaly know if it's the best option, most likely isn't, but I haven't been taught otherwise. I am aware that using the singleton pattern breaks encapsulation, and that it probably would actually be better to go with the other method mentioned in my post, so I may change that around now. In the meantime, I'll continue reading about the theory behind OOP which you kind folks have provided.

 

Yeah, this is generally why newbies use a Singleton.  It's still a bad way to go.  What you should use is Dependency Injection.  Since I suck at creating examples off the top of my head, look at: http://components.symfony-project.org/dependency-injection/trunk/book/01-Dependency-Injection

 

[dragon_sa]

@CPD or anyone really, can you recommend some good MVC turorial/learning sites?