Why and When to use OOP?
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Why and When to use OOP?
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...
- 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...
(#10850)
Re: Why and When to use OOP?
1. Formal Methods
2. Foresight (in making abstractions)
2. Foresight (in making abstractions)
Re: Why and When to use OOP?
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.
- Skoalbasher
- Forum Contributor
- Posts: 147
- Joined: Thu Feb 07, 2008 8:09 pm
Re: Why and When to use OOP?
I really do not understand anything said on this page. I feel I have a long way to go.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Why and When to use OOP?
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.Skoalbasher wrote:I really do not understand anything said on this page. I feel I have a long way to go.
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...
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Why and When to use OOP?
^^^ 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.
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?
@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
is better implemented using classes:
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);
}
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?
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.
Now if all services in the society have a clear responsibility and don't depend on others to much, the system works well.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Why and When to use OOP?
^^^ 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...
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?
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.It's not too much of a leap to see that [...] is better implemented using classes
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");Code: Select all
$rolodex = new Rolodex();
$person = new Person("John", "Doe", "", "john.doe@email.com");
$rolodex->addNew($person);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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Why and When to use OOP?
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.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:
you now need to do:Code: Select all
make_rolodex_entry("John", "Doe", "", "john.doe@email.com");
Code: Select all
$rolodex = new Rolodex(); $person = new Person("John", "Doe", "", "john.doe@email.com"); $rolodex->addNew($person);
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!
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.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.
(#10850)
Re: Why and When to use OOP?
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:I haven't a clue what make_rolodex_entry() does, or what side effects exist for it to do its job.
Yes, it's clearly in the $rolodex array. If you can't see that, just create yourself another function "get_rolodex_entry();"arborint wrote:Where is the Rolodex data? It must be somewhere.
You're not proving your point, you're just repeating "the second one is more clear" over and over again without justification.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,
Awesome. A reusable Person object. I'm sure that's very useful for a Rolodex program..arborint wrote:but you have created a reusable Person object that can be used elsewhere. Excellent work!
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.arborint wrote:Starting out with a design that is appropriate to deal with the complexity of the problem is the right path to follow.
Re: Why and When to use OOP?
You are the one who created a person object. If you don't need it, you can simply use:
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.
Code: Select all
$rolodex = new Rolodex();
$rolodex->addNew("John", "Doe", "", "john.doe@email.com");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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Why and When to use OOP?
But the entities and their relationships are clear in the OO code -- even without your fabulous, but missing, one line comment.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.
Not clear a all, but oops ...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();"
Code: Select all
$rolodex = "This is my Rolodex";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:You're not proving your point, you're just repeating "the second one is more clear" over and over again without justification.
Or a shipping program, or a mailing list, or attendance program, or ... Hey ... just about any program that deals with People!yh.h wrote:Awesome. A reusable Person object. I'm sure that's very useful for a Rolodex program..
You said always start with the simplest thing. I said start with the thing appropriate to the design -- which may be very complex.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.
(#10850)
Re: Why and When to use OOP?
but then I wouldn't be able to have "a reusable Person object that can be used elsewhere", as arborint suggestedpytrin 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");
I *totally* agree with you.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.
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:you only (erroneous) claim was that fewer lines of code is always clearer than more lines.
Well, hey... you were writing a rolodex program. Why did that change all of a sudden?arborint wrote:Or a shipping program, or a mailing list, or attendance program, or ... Hey ... just about any program that deals with People!
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.arborint wrote:start with the thing appropriate to the design -- which may be very complex.
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.