Page 3 of 4
Re: OO Usage Discussion
Posted: Thu Jun 12, 2008 5:52 pm
by Benjamin
pytrin wrote:Ok astions, I tried to go over your script but I quickly realized there are things missing...
This should clear things up a bit. This was put up in a rush today so I know it's bad.
http://adeframework.com/examples/destination_change
The registration_step_2 and step_3 are separate pages, all they contain is html however for the form.
Re: OO Usage Discussion
Posted: Fri Jun 13, 2008 2:09 am
by Ollie Saunders
If I may be so bold: Nobody is going to do anything cutting edge in the field of software engineering writing in PHP.
Smalltalk, Lisp, Ruby, Erlang, DSLs are the future!
Also aside from the design your code, astions how many projects have you applied your framework to? How much did it help? Has anyone else applied it to their projects? Have you iteratively revised your ideas as a result of continuous applied testing? I'm assuming the answers to all of these will be no or zero. Then everything you have done has been based on personal speculative or perhaps some anecdotal evidence.
If you want to create something truly useful you have to develop it in a way that you are able to constantly test that it is fulfilling that requirement: being useful. This way you can focus your efforts into the things that matter, solve the problems that need solving and gain an understanding how those problems vary and cater for those variances. Otherwise you can only expect to be on target a faction of the time and the rest of the framework will be fluff. The Zend Framework definitely suffered from this. Several times they release components that were completely useless. Fortunately they had the community to tell them so. But even they weren't offering people lots of options. In an ideal world there would be 10 different front controller implementations and we'd be able to gather all the data about which is best and when and then learn from that to create a more unified solution.
I'm being overly harsh here, nobody is actually doing this. The entire history of software development is littered with great ideas that were never properly tested presumably because doing so would be too difficult. Or by that time you've already implemented your idea so you might as well pimp it as much as possible. For me XML is the biggest example of this. I don't think XML will be around in 10 years time. God I hope not. I hate it for how much of my life it wasted.
Re: OO Usage Discussion
Posted: Fri Jun 13, 2008 12:51 pm
by Benjamin
Hi ole,
It's taken years to get it where it is today. I invite you to take a look at it and form an opinion. If there is enough support I'll open source it and then everyone else can use and contribute to it.
Re: OO Usage Discussion
Posted: Sat Jun 14, 2008 10:35 am
by VirtuosiMedia
Hi, I'm new here. I've been reading over this thread and so now I have a few questions. I've seen mentioned several times that some examples provided have basically been procedural code that makes use of classes and not true OOP. Don't you at least have to have some procedural code, though, to make use of the classes? Or for it to be true OOP, do you have to wrap absolutely everything into a class, even if you would use it only once? Does anyone have an example of what they would consider real OOP?
On a slightly different but related topic, which is considered better practice: class interdependence or independence? Personally, I would probably lean toward having as loose of coupling as possible for code reuse and so that things don't break as much when you change things, but I'm interested in what everyone else has to say about it. I would supspect that it would be partially situational, depending on what you need to accomplish.
Re: OO Usage Discussion
Posted: Sat Jun 14, 2008 11:40 am
by Christopher
VirtuosiMedia wrote:Hi, I'm new here. I've been reading over this thread and so now I have a few questions. I've seen mentioned several times that some examples provided have basically been procedural code that makes use of classes and not true OOP. Don't you at least have to have some procedural code, though, to make use of the classes? Or for it to be true OOP, do you have to wrap absolutely everything into a class, even if you would use it only once? Does anyone have an example of what they would consider real OOP?
I think in PHP you will inevitably have procedural code at the lowest level (i.e. within methods). The main distinction is whether the structure of the application is OOP or procedural. Defining classes and then just procedurally passing data through a series of methods is really just namespacing a procedural library using the class construct.
VirtuosiMedia wrote:On a slightly different but related topic, which is considered better practice: class interdependence or independence? Personally, I would probably lean toward having as loose of coupling as possible for code reuse and so that things don't break as much when you change things, but I'm interested in what everyone else has to say about it. I would supspect that it would be partially situational, depending on what you need to accomplish.
I don't think you want interdependence, because that would imply dependencies going both directions. Likewise complete independence would mean that objects would not rely on any other objects, so they really couldn't get any work done. For me the goal is clean, clear dependencies. The concepts of Low Coupling / High Cohesion are really central to software design. Low Coupling implies that only the minimal necessary dependencies are implemented. High Cohesion implies that you a clearly Separating Concerns which in turn supports ideas like Modularity and DRY.
Re: OO Usage Discussion
Posted: Sat Jun 14, 2008 3:10 pm
by VirtuosiMedia
arborint wrote:I think in PHP you will inevitably have procedural code at the lowest level (i.e. within methods). The main distinction is whether the structure of the application is OOP or procedural. Defining classes and then just procedurally passing data through a series of methods is really just namespacing a procedural library using the class construct.
I'd like just a little more clarification, if you don't mind. Are you saying that OO application structure should be able to initiate the methods on its own? As a simplified example, would building a page based off URL parameters qualify if the different components are included through an autoload method or some sort of controller? (Joomla does something similar to this, but it may not be the best example). Staying fairly abstract for the moment, what would be the definition of an OO application structure?
arborint wrote:I don't think you want interdependence, because that would imply dependencies going both directions. Likewise complete independence would mean that objects would not rely on any other objects, so they really couldn't get any work done. For me the goal is clean, clear dependencies. The concepts of Low Coupling / High Cohesion are really central to software design. Low Coupling implies that only the minimal necessary dependencies are implemented. High Cohesion implies that you a clearly Separating Concerns which in turn supports ideas like Modularity and DRY.
I think what I meant to say was dependence rather than interdependence. What you wrote makes sense to me, though. So just as general rules, then:
Use abstract base classes and extend them
Reuse code where you can
Keep the number of dependencies as low as possible
Create clear documentation of dependencies
Does that sound right?
Re: OO Usage Discussion
Posted: Sat Jun 14, 2008 5:15 pm
by Christopher
VirtuosiMedia wrote:I'd like just a little more clarification, if you don't mind. Are you saying that OO application structure should be able to initiate the methods on its own?
I think I am saying that the structure of the application should be a bunch of objects. Within the methods, in PHP, you will drop into some standard Structured Programming.
VirtuosiMedia wrote:As a simplified example, would building a page based off URL parameters qualify if the different components are included through an autoload method or some sort of controller? (Joomla does something similar to this, but it may not be the best example). Staying fairly abstract for the moment, what would be the definition of an OO application structure?
"building a page based off URL parameters" has nothing to do with the methodology, that's just where the data comes from and what it is used for. If the parameters were converted to objects using the Command pattern (as is commonly done) then that would be OO. Using __autoload implies using classes because it is the error handler for class references.
VirtuosiMedia wrote:Use abstract base classes and extend them
The current preference is composition over inheritance. That is a discussion in itself.
VirtuosiMedia wrote:Reuse code where you can
Reuse can mean many things and concepts like DRY are about specific kinds of reuse
VirtuosiMedia wrote:Keep the number of dependencies as low as possible
Dependencies are necessary and good things, the important thing is that they correct. That often simply means that the only go in one direction and that they respect layer boundaries.
VirtuosiMedia wrote:Create clear documentation of dependencies
Or interfaces that enforce them, or tests that specify them....
Re: OO Usage Discussion
Posted: Sat Jun 14, 2008 5:27 pm
by VirtuosiMedia
Okay, that makes sense. Thanks for the clarification. I'm not always clear on all my terms because I'm still learning PHP, so that helped.
Re: OO Usage Discussion
Posted: Tue Jun 17, 2008 10:44 pm
by Benjamin
arborint wrote:Sure you are using the class construct, but essentially just namespacing your procedural function library with $_KERNEL.
I am reading C++, Primer Plus by Stephan Prata in order to get a different perspective on programming. From what I have read so far, I can see how you can view what I have done as "namespacing a procedural function library". I look at it from a different angle though.
Essentially, I look at classes as:
1. A module of code that performs a specific action.
2. Blocks of code that should function on their own with minimum dependencies.
3. A way to organize code.
4. A way to take a complex task and divide it into organized pieces by using methods.
5. A style of programming that allows me to reuse code in other applications.
arborint wrote:It is really not OOP at all.
OOP Stands for Object Oriented Programming. The second word, "Oriented" is ambiguous. How can I determine what the true definition of OOP is, when it contains ambiguity?
If 90% of my code uses classes, and if classes are considered objects, why is it not reasonable for one to conclude that it is "Object Oriented Programming"?
Re: OO Usage Discussion
Posted: Tue Jun 17, 2008 10:56 pm
by Ollie Saunders
Don't read too much into the name alone. OOP implies a whole bunch of things that make up a fairly specific definition.
I'd say you are spot on with the first 4 of your 5 points. The point of OO isn't really reusability. It is more adaptive, so you can apply things to more varied scenarios in the same way that parameters allow a function to be more adaptive and modifiable but OO alone is not the path to true reusability nor is it really the point. Reusability especially to the level that would be involved for cross-application reusability is a much more complex, harder to achieve thing.
Re: OO Usage Discussion
Posted: Tue Jun 17, 2008 11:17 pm
by Benjamin
ole wrote:The point of OO isn't really reusability. It is more adaptive, so you can apply things to more varied scenarios in the same way that parameters allow a function to be more adaptive and modifiable but OO alone is not the path to true reusability nor is it really the point. Reusability especially to the level that would be involved for cross-application reusability is a much more complex, harder to achieve thing.
Hi Ole, thank you for the insight.
I believe you are saying that the point of OO isn't for reusability because OO allows you to apply things to more varied scenarios and because reusability is much more complex. I have interpreted your use of "cross-application" to mean "different web based application with different requirements".
If that is the case, why would someone want an OO framework? Wouldn't they prefer a framework that contained a library of easy to access reusable code that they could use on a variety of projects? Consider that the framework in this case would allow OO programing on top of the predefined library.
Re: OO Usage Discussion
Posted: Wed Jun 18, 2008 12:48 am
by Christopher
astions wrote:1. A module of code that performs a specific action.
2. Blocks of code that should function on their own with minimum dependencies.
3. A way to organize code.
4. A way to take a complex task and divide it into organized pieces by using methods.
5. A style of programming that allows me to reuse code in other applications.
astions wrote:If 90% of my code uses classes, and if classes are considered objects, why is it not reasonable for one to conclude that it is "Object Oriented Programming"?
When you understand why is it not reasonable, then you will understand OOP...
Re: OO Usage Discussion
Posted: Wed Jun 18, 2008 1:26 am
by Benjamin
arborint wrote:When you understand why is it not reasonable, then you will understand OOP...
That's Begging the Question, a common fallacy used during arguments/discussions.
Are you saying that the word code should be replaced with the word object? That is something I explicitly avoid. Should the need to do so arrive, I will, but it would seem as if you are saying that I do not understand OOP because I do not use or avoid this particular programming methodology. I am not convinced.
I do not doubt that what you describe as OOP has significant benefits. What I doubt is that it is beneficial to write all code in that way, considering the increased planning and development time required weighed against unknown or unlikely future amendments and additions to a codebase.
Re: OO Usage Discussion
Posted: Wed Jun 18, 2008 2:36 am
by John Cartwright
Can't teach an old dog new tricks, they say. Better yet, can't teach a new dog old tricks.
My take: OOP has very little to do with the code, it's all interface baby.
Re: OO Usage Discussion
Posted: Wed Jun 18, 2008 3:23 am
by Christopher
astions wrote:That's Begging the Question, a common fallacy used during arguments/discussions.
Actually my statement was not a circular argument and here's why: your statement
"if classes are considered objects, why is it not reasonable for one to conclude that it is "Object Oriented Programming"?" is actually Begging the Question because classes != objects and classes != OOP. Hence my comment about understanding what objects and OOP are...
astions wrote:Are you saying that the word code should be replaced with the word object? That is something I explicitly avoid. Should the need to do so arrive, I will, but it would seem as if you are saying that I do not understand OOP because I do not use or avoid this particular programming methodology. I am not convinced.
No, you should replace the word "code" with "data".
And I want to be clear -- I know that I cannot convince you on this subject -- nor have I or am I trying to convince you. You will need to convince yourself.
astions wrote:I do not doubt that what you describe as OOP has significant benefits. What I doubt is that it is beneficial to write all code in that way, considering the increased planning and development time required weighed against unknown or unlikely future amendments and additions to a codebase.
You are basing your argument on the hypothetical "increased planning and development time" of a methodology you may not understand.
Not sure what to say about a system designed for projects with "unlikely future amendments"...