Page 2 of 3
Re: Why and When to use OOP?
Posted: Tue Feb 03, 2009 8:53 pm
by Christopher
You know ... we are talking about this OOP thing a lot. However, I think when we do we are also talking about a bunch of related concepts that are the ideas behind best practices. Things like:
- Separation of Concerns
- Premature Optimization
- DRY
- The importance of interfaces
- Loose Coupling / High Cohesion
- etc. (Please add more as it would be an interesting list)
think my point is that it is difficult to talk about "why OO or not?" unless you understand most if not all of these concepts. We end up arguing details rather than understanding how we got here...
Re: Why and When to use OOP?
Posted: Tue Feb 03, 2009 9:19 pm
by nor0101
1. Formal Methods
2. Foresight (in making abstractions)
Re: Why and When to use OOP?
Posted: Tue Feb 03, 2009 10:07 pm
by josh
Minimizing cognitive ( mental ) energy needed to read a piece of code ( goes hand in hand with DRY ). Creating a more semantic API that reads more like a natural language. Law of demeter ( dont have $foo->getBar()->getWidget()->getTitle()->isEmpty(), stuff that in a helper method so you can just do $foo->WidgetHasTitle() ). Law of demeter is 1 of the facts I refer to when I say minimizing cognitive load. And if you want to talk about that the next natural topic to talk about would be refactoring, and unit testing.
Re: Why and When to use OOP?
Posted: Tue Feb 03, 2009 10:35 pm
by Skoalbasher
I really do not understand anything said on this page. I feel I have a long way to go.
Re: Why and When to use OOP?
Posted: Tue Feb 03, 2009 11:05 pm
by Christopher
Skoalbasher wrote:I really do not understand anything said on this page. I feel I have a long way to go.
I think that was my point. You have to understand a bunch of ideas before you can see why you might want to use OOP. And then you actually have to come across all the problems that OO solves nicely and actually solve them using OOP to really, really see why.
It's like trying to understand Calculus without first understanding Algebra/Geometry/Trigonometry/etc. There is perquisite knowledge.
I would recommend searching and reading about some of those, and about OOP...
Re: Why and When to use OOP?
Posted: Tue Feb 03, 2009 11:16 pm
by alex.barylski
^^^ Ditto
Although there is little harm in learning OOP and never bothering with procedural code, if you want to "understand" why OOP is used you need experience, it's that simple.
It's like questioning whether to use a framework or not.
Write an enterprise application with no structure/architecture or design goals and after about 30K lines you begin to realize the benfits of maybe thinking a little more about design.
You can ask in forums and can people can do theri best to explain and sell you on the idea (which is what everyone does -- as geeks we are all passionate about our beloved solutions) but ultimately its your understanding and experience that decide for you.
Re: Why and When to use OOP?
Posted: Tue Feb 03, 2009 11:38 pm
by nor0101
@PC Spectra: Well said. I think there is value in learning a language in its entirety right from the get-go however. Even if the first few projects are done without writing a single class, it's great that the OP has at least a feel for how classes are implemented in PHP. When a more complex task comes along an epiphany might come, "hey, wonder if I should write a class to model this". It's not too much of a leap to see that
Code: Select all
$rolodex = Array();
function make_rolodex_entry($firstName, $lastName, $phone, $email) {
global $rolodex;
$rolodex[] = new Array("firstName"=>$firstName, "lastName"=>$lastName,
"phone"=>$phone, "email"=>$email);
}
is better implemented using classes:
Code: Select all
class Rolodex() {
private $rdx = Array();
public function addNew($person);
public function search($terms);
public function sort($how);
// etc.
}
class Person {
private $firstName, $lastName, $phone, $email;
public function __construct($fn, $ln, $p, $em) {
$this->firstName = $fn;
$this->lastName = $ln;
$this->phone = $p;
$this->email = $em;
}
// getters & setters, etc.
}
Re: Why and When to use OOP?
Posted: Wed Feb 04, 2009 1:36 am
by matthijs
The way I understand OOP is that it's about organization of code. The same way you would organize a society. You don't want everybody to have to bake his own bread or mail his own post. So you have only one organization to do the postal service. That's it's responsibility. You don't care how the postal service does it, as long as it's done. For you as an end user it's easy. Posting something means 1) stamp 2) put in mailbox. Getting post is as easy as having a mailbox in your front door.
Now if all services in the society have a clear responsibility and don't depend on others to much, the system works well.
Re: Why and When to use OOP?
Posted: Wed Feb 04, 2009 10:20 am
by alex.barylski
^^^ What I find interesting is how every developer uses anologies to real world industries to understand/comprehend OOP.
I personally use airplanes and building architecture to explain concepts.
I love looking at skylines and watching airplanes...

Re: Why and When to use OOP?
Posted: Fri May 01, 2009 1:44 am
by yh.h
It's not too much of a leap to see that [...] is better implemented using classes
I have to weigh in on this. I think it is a huge leap you're making. You can't just assume OOP is always better than procedural because it seems like it makes your life simpler. In this case, it clearly does not. Too much simplicity for the sake of simplicity becomes overkill.
You just nearly doubled the number of lines and tripled the complexity, not to mention you didn't show the getter and setter methods, which would have made things worse.
Look at the first code. At a glance, you know exactly what it does. Look at the second. What on earth is that? Instead of doing:
Code: Select all
make_rolodex_entry("John", "Doe", "", "john.doe@email.com");
you now need to do:
Code: Select all
$rolodex = new Rolodex();
$person = new Person("John", "Doe", "", "john.doe@email.com");
$rolodex->addNew($person);
That's just absurd, wouldn't you agree?
Now of course, you're going to say "what if the program changes later". If it does, then change it. Pretending you can think of all possible ways in which a program might change ahead of time is fooling yourself. Making things more complicated early on will only make your life harder.
You always want the simplest solution first. OOP is not the cure to all your problems.
Re: Why and When to use OOP?
Posted: Fri May 01, 2009 2:13 am
by Christopher
yh.h wrote:Look at the first code. At a glance, you know exactly what it does. Look at the second. What on earth is that? Instead of doing:
Code: Select all
make_rolodex_entry("John", "Doe", "", "john.doe@email.com");
you now need to do:
Code: Select all
$rolodex = new Rolodex();
$person = new Person("John", "Doe", "", "john.doe@email.com");
$rolodex->addNew($person);
I think you are making the opposite point than you intend to make. I haven't a clue what make_rolodex_entry() does, or what side effects exist for it to do its job. Where is the Rolodex data? It must be somewhere.
Now look at your (improved, thanks) second OOP example. Not only is is clear what is going on and where the data is, but you have created a reusable Person object that can be used elsewhere. Excellent work!
yh.h wrote:That's just absurd, wouldn't you agree?
Now of course, you're going to say "what if the program changes later". If it does, then change it. Pretending you can think of all possible ways in which a program might change ahead of time is fooling yourself. Making things more complicated early on will only make your life harder.
You always want the simplest solution first. OOP is not the cure to all your problems.
You are being misleading by talking about complexity and simplicity, rather than worse design and better design. Complexity has to do with the problem to be solved. Some problems are more complex than others. Starting out with a design that is appropriate to deal with the complexity of the problem is the right path to follow. I am not sure what "making things complicated early on" really means, but when solving a complex problem, it will not make your life harder in the long run to design for that complexity.
Re: Why and When to use OOP?
Posted: Fri May 01, 2009 11:48 am
by yh.h
arborint wrote:I haven't a clue what make_rolodex_entry() does, or what side effects exist for it to do its job.
A one line comment above the function would solve that. Seriously people, cut the crap. You're saying that you can't understand 6 simple lines of code, yet you have no problem understanding 15 lines with two classes and 4 methods? And I could tell you the same thing.. I haven't a clue what the two classes do or what side effects exist for it to do its job.
arborint wrote:Where is the Rolodex data? It must be somewhere.
Yes, it's clearly in the $rolodex array. If you can't see that, just create yourself another function "get_rolodex_entry();"
arborint wrote:Now look at your (improved, thanks) second OOP example. Not only is is clear what is going on and where the data is,
You're not proving your point, you're just repeating "the second one is more clear" over and over again without justification.
arborint wrote:but you have created a reusable Person object that can be used elsewhere. Excellent work!
Awesome. A reusable Person object. I'm sure that's very useful for a Rolodex program..
arborint wrote:Starting out with a design that is appropriate to deal with the complexity of the problem is the right path to follow.
THANK YOU, but I don't see how this proves your point. This program is very far from being complex; it is so simple it doesn't need more than one or two functions.
Re: Why and When to use OOP?
Posted: Fri May 01, 2009 12:10 pm
by Eran
You are the one who created a person object. If you don't need it, you can simply use:
Code: Select all
$rolodex = new Rolodex();
$rolodex->addNew("John", "Doe", "", "john.doe@email.com");
And it would be very similar to the procedural code. It is one line more (yep, objects have to be instanced), but nobody expects that two lines of code would prove or disprove the validity of an entire methodology. It does however create a namespace for rolodex functions (the rolodex class), so it has at least that to its advantage. Rolodex functions therefor have a logical scope.
By the way this "application" is obviously not indicative of any real-world situation, since those are usually considerably more complex.
OOP design can be used to solve many common problems in handling software complexity. You can achieve similar results with procedural programming (and people have) but you have less tools and language semantics at your disposal, meaning you have to work harder. Obviously blindly grouping functions into classes and calling it OOP is not going to create a better design. Better developers create better design, regardless of the tools they use.
Re: Why and When to use OOP?
Posted: Fri May 01, 2009 3:03 pm
by Christopher
yh.h wrote:A one line comment above the function would solve that. Seriously people, cut the crap. You're saying that you can't understand 6 simple lines of code, yet you have no problem understanding 15 lines with two classes and 4 methods? And I could tell you the same thing.. I haven't a clue what the two classes do or what side effects exist for it to do its job.
But the entities and their relationships are clear in the OO code -- even without your fabulous, but missing, one line comment.
yh.h wrote:Yes, it's clearly in the $rolodex array. If you can't see that, just create yourself another function "get_rolodex_entry();"
Not clear a all, but
oops ...
Hey, how come my rolodex function doesn't work anymore!
yh.h wrote:You're not proving your point, you're just repeating "the second one is more clear" over and over again without justification.
No, you claimed the first was clearer and better. You only (erroneous) claim was that fewer lines of code is always clearer than more lines. I show several ways that the OO one gives more information implicitly (without a comment).
yh.h wrote:Awesome. A reusable Person object. I'm sure that's very useful for a Rolodex program..
Or a shipping program, or a mailing list, or attendance program, or ... Hey ... just about any program that deals with People!
yh.h wrote:THANK YOU, but I don't see how this proves your point. This program is very far from being complex; it is so simple it doesn't need more than one or two functions.
You said always start with the simplest thing. I said start with the thing appropriate to the design -- which may be very complex.
Re: Why and When to use OOP?
Posted: Fri May 01, 2009 4:57 pm
by yh.h
pytrin wrote:You are the one who created a person object. If you don't need it, you can simply use:
Code: Select all
$rolodex = new Rolodex();
$rolodex->addNew("John", "Doe", "", "john.doe@email.com");
but then I wouldn't be able to have "a reusable Person object that can be used elsewhere", as arborint suggested
pytrin wrote:Obviously blindly grouping functions into classes and calling it OOP is not going to create a better design. Better developers create better design, regardless of the tools they use.
I *totally* agree with you.
arborint wrote:you only (erroneous) claim was that fewer lines of code is always clearer than more lines.
You're putting words in my mouth. I was comparing both snippets of code and showing the unnecessary complexity of the OOP version.
arborint wrote:Or a shipping program, or a mailing list, or attendance program, or ... Hey ... just about any program that deals with People!
Well, hey... you were writing a rolodex program. Why did that change all of a sudden?
arborint wrote:start with the thing appropriate to the design -- which may be very complex.
That's very true, but in the case of making a rolodex program, the degree of complexity you suggested surpasses (by far) what is needed.
I want to make it clear that I'm not bashing OOP. OOP is very useful but is *often* misused. And I would really like to see more non-trivial examples of where OOP makes sense and should be used, especially in introductory programming classes.