What's the real benefit of OOP?

[webaddictz]

@lastcraft

Once you’ve learned the basic syntax and mechanics, get a copy of “Refactoring” by Martin Fowler. That book empowers you with OO fu without you even noticing.

+1 on Refactoring. It truly is an excellent book.

[lastcraft]

Hi…

Once you’ve learned the basic syntax and mechanics, get a copy of “Refactoring” by Martin Fowler. That book empowers you with OO fu without you even noticing.

yours, Marcus

[GHOwner]

@praetor

Be careful that OOP is all about the mindset. Many write procedural code wrapped up in classes. Using classes is not OOP, but thinking in objects like in real life. Familiarize yourself with concepts such as DRY (Don’t repeat yourself), The open-closed principle, design patterns, abstraction , polymorphism etc. Learn by doing it, start a project let’s say a forum or an extensible blog and think like a human :). For example: in a blog you have the object Post which has properties like title, content but also contains a list of other objects, the Comments.

And I give you a very useful hint: FORGET about the database. Think only about your objects and how they behave, ignore that you have a database. Use the Repository pattern to make this easier.

Thanks, it’ll just take some time to understand. I’ve skipped that part of the book for now, but plan to revisit as needed. Just gonna understand the main build up and then work on making it efficient by the use of OOP.

[praetor]

Be careful that OOP is all about the mindset. Many write procedural code wrapped up in classes. Using classes is not OOP, but thinking in objects like in real life. Familiarize yourself with concepts such as DRY (Don’t repeat yourself), The open-closed principle, design patterns, abstraction , polymorphism etc. Learn by doing it, start a project let’s say a forum or an extensible blog and think like a human :). For example: in a blog you have the object Post which has properties like title, content but also contains a list of other objects, the Comments.

And I give you a very useful hint: FORGET about the database. Think only about your objects and how they behave, ignore that you have a database. Use the Repository pattern to make this easier.

[GHOwner]

Thanks guys. You make some good points and I am studying it. Just still understanding the structure and how to use it appropriately will take time. I want to make applications that are extensible, so that’s why I’m looking on this more, other than the obvious reason.

[Mastodont]

Why make a class when a file of functions can do the same?

You can much better model the application. Classes represent some logic entity with responsibilities. If you write a blog, you need articles, some template, maybe users etc. Mostly these basic entities come out after simple analysis.

You can build new classes with modified behaviour and actions from their parent classes, this is impossible with functions.

A class can share more variables for different methods (functions). With functions you need awful “global”.

Function is always only a hammer, class is a clever gadget.

[felgall]

It makes reusing code much easier.

[PHPycho]

Consider a very large project, Work on a team, Work on RFCs…etc
You will know the real benefit of OOP

[iackay]

Well, if you have to ask then you really haven’t done any homework on what OOP affords you. Classes are essentially data structures for functions, like a STRUCT in C is a data structure for a group of variables.

The OOP nature of C++, Java and the rest just allow you to implement inheritance differently and offer support structures. Many of those support structures are standard through most OOP languages.

For instance, in php5 you’ll get into interfaces and abstract classes. These are the real soldiers of keeping your code clean. And by that I mean, code resuse. It is nothing to implement functional programming in classes. In fact that isn’t too different than considering a STRUCT a basic feature of OOP in pure C. It depends on how much you are going to defend that against people who think they are smarter than you.

But the where the real benefits come into play is when you start to think in terms of inheritance especially with interfaces and abstract classes, which lead you into static methods etc etc.

You can then start to think in terms of composite objects built up in groups of interfaces to build completely new objects… yet you are not going off and really making new things now are you? It basically lets you build a blueprint of your application and still read similarly.

Abstracts allow you to have independent implementations of methods without having to keep overloading your functions now doesn’t it? If you have one abstract method, you need to declare an abstract class.

Static methods you get from declaring an static keyword offer very functional ways of using methods without instancing the object…

So there are real ways of using OOP to your advantage that just make sense. Sure, you could make a procedural application in C or php but after a while but you might have maintained the code differently if you had of built it a different way.

It really all just depends on your concept and how you follow through with it. OOP offers many benefits. And you can always use both ways. In MVC sites, helpers are normally just functions where libraries are classes. At least in CodeIgniter. Right tool for the right job.

[lastcraft]

Hi…

@iackay

Well, if you have to ask then you really haven’t done any homework on what OOP affords you.

This is a little unfair. There are plenty of traps hidden in the mechanics of OO. Overuse of inheritance for an obvious example, and the one people often crash into first.

For learning, I find it better to restrict the mechanical choices initially. I had a long time coaching assignment with a CEO and we had a sort of ban on static methods and anything more than one level of inheritance. This forced us to work with the paradigm. We never had to break either rule.

@iackay

Classes are essentially data structures for functions, like a STRUCT in C is a data structure for a group of variables.

You go through stages of understanding. “Smart data” is definitely a good starting point. Later on the data becomes an implementation detail, trumped by behaviour. Then you learn the exceptions. Then you learn to abuse the syntax in the name of DSLs.

@iackay

For instance, in php5 you’ll get into interfaces and abstract classes. These are the real soldiers of keeping your code clean.

These enforce conventions when interfacing with your code. I’d argue that they are mostly bloat inside a package when all the developers are savvy. YMMV.

Crafting abstract interfaces is also a skillful job. Not for the beginner. I would leave interfaces and abstract classes for later.

@iackay

It depends on how much you are going to defend that against people who think they are smarter than you.

How do you tell these people from those that are more experienced and are giving good advice?

@iackay

But the where the real benefits come into play is when you start to think in terms of inheritance

Ouch. Inheritance is best used for very minor variations of subclasses. You can only play that card once and you can get yourself into a right tangle. If you want to severely alter the behaviour of a class, possibly use a Strategy pattern. Or just use a completely different class with the same interface.

@iackay

You can then start to think in terms of composite objects built up in groups of interfaces to build completely new objects… yet you are not going off and really making new things now are you? It basically lets you build a blueprint of your application and still read similarly.

I’d agree with that. I don’t think reuse is a useful goal - it tends to emerge later after a period of refactoring. The real benefit of OO is decomposing the problem in a way that you can understand and in a way that you can test subcomponents independently.

yours, Marcus

[sunwukung]

@arborint

Though perhaps meant as a joke, these kind of comments belittle the huge improvement to software design that OOP and Patterns have brought to us. Let us not forget the revolutionary contribution that the GoF era thinkers made to our craft. You can joke, but there has been no serious book about procedural programming in a decade. It is a historic paradigm that is now just a subset of what is possible with OOP.

Given the same facts regarding book content, OOP’s reputation is hardly in jeopardy on the back of a glib forum post.

Just for the record, I’m a big fan of OOP - check the content of my posts (and my profile on Stack - same name). It’s just meant as a bit of fun…

[arborint]

@lastcraft

When writing UI interaction code I want to be presented with a palette with which to paint. It’s more like a documents than code, so DRY is not useful (otherwise I’d work off of the zip compressed version). Functions like h() and link() make my job a lot easier. Having to code 20+ lines of view helper, and then debug the thing, doesn’t.

Interesting. I understand how short names make it easier. I am not sure how link() and $this->link() are that much different? And what about the autoloading on demand that helpers provide? Do you include just what you need or include everything you could possible ever use?