I was asking myself how much sense it does to use design patterns with php5.
For example if I'm designing a component with a interface, it's implementation (which should be hidden, package private exists?) and a factory (which handles it's references).
What's your opinion about that?Makes as much sense as using design patterns in any other language.One of PHP5's biggest strengths over previous releases is it's ability to utilize OO design patterns better.
If you think you were using real design patterns in pre-PHP5 releases, you were mistaken.I like using the singleton pattern for database connections and LDAP. That way I never open multiple connections. Just as an example...
The decision to use design patterns or not really comes down to how much development you are doing. If you do a lot, then it makes sense to reuse code as much as possible and design patterns tend to create reusable code. So from that standpoint, it would be a good idea. Just my two cents...I'm aware of the advantage of design patterns, I'm just a bit confused what it means for PHP as a script language and people saying that PHP is not really OO.
Hear is what I'd like to do:
- I was thinking to use the MVC pattern as the main 'code organizing' part.
- Util packages with interfaces, factories and its implementation.
- the composit pattern to build some view components
Thanks for your replay
borobudurYou raise a valid point. PHP is a scripting language, though we often tend to forget that fact. And HTTP is stateless so all our frameworks and class files need to be loaded for every request. I'm afraid I don't have a good answer for you other than to say that I'm a firm believer in OO and design patterns. I think the discipline and organization inherent in that approach more than make up for any performance hit. Besides there are many other ways to boost performance besides writing every procedural...Things are only as OO as you make them. I can take Java, a complete OO language, and write a procedural program too.I agree with this:I think the discipline and organization inherent in that approach more than make up for any performance hit.
It's more important that you know what you're doing than worrying about the syntax you write it in. Because that's all there is between programming languages; some are better at some things than others because (shock, horror) they were each designed with different goals. The latest programming paradigm du jour might be easy to do in a language specifically designed to support it, but that's no surprise. But in the end it all gets rendered down into a language that doesn't have MVC frameworks, doesn't have objects, doesn't have functions, doesn't have variables, doesn't have operators, and doesn't have numbers. And yet it still works and still does everything those other fancy things do.
Still, I also agree with this:I'm just a bit confused what it means for PHP as a script language and people saying that PHP is not really OO."Script language" and "really OO" are more of those abstract concepts that don't have much of a formal definition. What are the defining characteristics of a "scripting language"? Distributed as runtime-compiled source code? Capable of self-modification? Loosely-typed? And does it matter when it comes to design patterns? The answer to the last question is no: it does not. To think it does is a pure category error; like confusing "weather" with "climate", or "lake" with "water", or "forest" with "trees".
For example if I'm designing a component with a interface, it's implementation (which should be hidden, package private exists?) and a factory (which handles it's references).
What's your opinion about that?Makes as much sense as using design patterns in any other language.One of PHP5's biggest strengths over previous releases is it's ability to utilize OO design patterns better.
If you think you were using real design patterns in pre-PHP5 releases, you were mistaken.I like using the singleton pattern for database connections and LDAP. That way I never open multiple connections. Just as an example...
The decision to use design patterns or not really comes down to how much development you are doing. If you do a lot, then it makes sense to reuse code as much as possible and design patterns tend to create reusable code. So from that standpoint, it would be a good idea. Just my two cents...I'm aware of the advantage of design patterns, I'm just a bit confused what it means for PHP as a script language and people saying that PHP is not really OO.
Hear is what I'd like to do:
- I was thinking to use the MVC pattern as the main 'code organizing' part.
- Util packages with interfaces, factories and its implementation.
- the composit pattern to build some view components
Thanks for your replay
borobudurYou raise a valid point. PHP is a scripting language, though we often tend to forget that fact. And HTTP is stateless so all our frameworks and class files need to be loaded for every request. I'm afraid I don't have a good answer for you other than to say that I'm a firm believer in OO and design patterns. I think the discipline and organization inherent in that approach more than make up for any performance hit. Besides there are many other ways to boost performance besides writing every procedural...Things are only as OO as you make them. I can take Java, a complete OO language, and write a procedural program too.I agree with this:I think the discipline and organization inherent in that approach more than make up for any performance hit.
It's more important that you know what you're doing than worrying about the syntax you write it in. Because that's all there is between programming languages; some are better at some things than others because (shock, horror) they were each designed with different goals. The latest programming paradigm du jour might be easy to do in a language specifically designed to support it, but that's no surprise. But in the end it all gets rendered down into a language that doesn't have MVC frameworks, doesn't have objects, doesn't have functions, doesn't have variables, doesn't have operators, and doesn't have numbers. And yet it still works and still does everything those other fancy things do.
Still, I also agree with this:I'm just a bit confused what it means for PHP as a script language and people saying that PHP is not really OO."Script language" and "really OO" are more of those abstract concepts that don't have much of a formal definition. What are the defining characteristics of a "scripting language"? Distributed as runtime-compiled source code? Capable of self-modification? Loosely-typed? And does it matter when it comes to design patterns? The answer to the last question is no: it does not. To think it does is a pure category error; like confusing "weather" with "climate", or "lake" with "water", or "forest" with "trees".