OOP or not? when to OOP

blackhorse

In percentage, how much of your php developing is in OOP, how much is in procedural programming?

In my cases, I use OOP for interacting with 3rd party (such as Google Applications map, direction, base etc.), for the view layer (such as display pages to the front end user), for the general purpose features (such as articles, news, events, gallery), for the projects I am with experience before, for as part of the big team projects.

I use procedural programming for small, custom design projects/features, for the new and small projects, for model and controller layer when interacting with the database (when update/insert/edit, I don't see too many benefits use oop rather than procedural programming, when select, the select results already object like when fetch object, even it is not strictly following the OOP rule). But I am turning some of the above developing I used to do on procedural programming to OOP. I want to switch more and more to OOP but I don't want to do it for the wrong reasons just because it is OOP. Also I want to switch to OOP in a right order, the most suitable parts first.

My question is in your experience and opinions, in what kind projects/area/layer to use OOP and in what cases to use procedural programming?

Thanks!

NogDog

Month by month as I get more proficient with OOP/OOD, I use it more an more. For very trivial projects I'll still use mostly/all procedural code, but as I progress my definition of "trivial" becomes smaller and smaller. For a site of any complexity my weapon of choice right now is CodeIgniter, which generally means I end up writing about 50-75% OOP code and the rest is procedural code either in views or helper functions. (And of course that is then bound up with the underlying CI code which is primarily OOP.)

laserlight

blackhorse wrote:
In percentage, how much of your php developing is in OOP, how much is in procedural programming?

I find that tough to answer, because the lines between OOP and procedural programming can be blurred by the fact that OOP is something of an extension to procedural programming. For example: is it procedural programming when you write a bunch of free functions that use PHP interface constructs for parameter type hinting? Is it OOP when you write a bunch of static member functions that effectively use the class as nothing more than a namespace? What if you define classes and instantiate objects, but never ever use inheritance or implement interface constructs?

blackhorse

" Is it OOP when you write a bunch of static member functions that effectively use the class as nothing more than a namespace? What if you define classes and instantiate objects, but never ever use inheritance or implement interface constructs?" As a matter of fact, I am doing some of these now. Even it doesn't use the inheritance, it still makes the codes easy to read, simple, small, clean due to it still follows the common rule of OOP, people knows what your codes doing with a quick look.

I am switching from procedural to oo, basically, I want to know which part I should switch to OOP first based on other people's experience.

laserlight

blackhorse wrote:
Even it doesn't use the inheritance, it still makes the codes easy to read, simple, small, clean due to it still follows the common rule of OOP, people knows what your codes doing with a quick look.

What is the "common rule of OOP"?

blackhorse

laserlight;10907969 wrote:
What is the "common rule of OOP"?

Well, that is just my experience, if I read functions codes, I would have to kind take more time to see how these functions work, they work on what values, what functions return these values, how these functions interact with other codes. And each developer may have his own way to write functions.

But if in class, values are in class variables. set functions to set the values, get functions to get the values, etc. that is oop 101. Most people will do the same way. When you read class code, you know what you expect for. It is more structural.

In simple words, I think even no inheritance, if the code is write in class rather than just function, in most cases, it is cleaner and simpler. You may not call it 100% OOP, but still a good programming practice.

laserlight

blackhorse wrote:
Well, that is just my experience, if I read functions codes, I would have to kind take more time to see how these functions work, they work on what values, what functions return these values, how these functions interact with other codes. And each developer may have his own way to write functions.

That is true, but the methods of a class are functions, and these same ideas of the pre-conditions and post-conditions of functions apply to methods.

blackhorse wrote:
But if in class, values are in class variables. set functions to set the values, get functions to get the values, etc. that is oop 101. Most people will do the same way. When you read class code, you know what you expect for.

A class that consists (almost) entirely of getter and setter functions might not be very well designed, since it might not be providing the correct abstractions for what the class is supposed to model.

blackhorse wrote:
In simple words, I think even no inheritance, if the code is write in class rather than just function, in most cases, it is cleaner and simpler. You may not call it 100% OOP, but still a good programming practice.

Ah, but doesn't that complicate the answering of your original question? 😃 If it is not 100% OOP, what percentage of OOP is it? :p

Now, let me present another scenario: you define a class and release it as part of a library. Some time later, some users of your library request that you extend the class' functionality by providing some convenience functions. These convenience functions can be implemented entirely using the public interface of your class, with negligible impact on performance. Would you make them methods or free functions, or would you use inheritance?

Chances are, I would choose the make them free functions. The reason is that if you make them members, then you decrease the encapsulation of the class, in the sense that a change to the implementation of the class requires you to check more functions to see what impact that change might have. If they are free functions instead, then as long as the methods that they rely upon do not change in functionality, they too will not change in functionality. The use of inheritance is feasible, but you may need to implement extra code, e.g., to forward constructor invocations.

The point is that the use of free functions here increase, not decrease, encapsulation, and encapsulation is one of the things people consider when they talk about OOP. In other words, a naive "compare how much code is in free functions versus how much code is in classes" is not a good gauge of the extent that OOP is used.

Weedpacket

I'm wondering if we'll be seeing more functional programming in PHP in the future; up until now its functional programming support has been pretty weak, but newer versions have gone a long way towards addressing that.

I just wish closures could be properly serialised; (actually, I wish program state could be serialised). The problem is that the important feature of the closure is a method, and methods don't get serialised.

I'd like to try using continuation-passing style in sessions. It's possible now, but only at the expense of making the code massively unreadable - defeating the purpose.

$errors = null
do
{
    $user = get_login_from_user($errors);
} while($errors !== null);

After that, I'd like to have a 'yield' construct in PHP for iterators, please 🙂 It's getting old writing my own state machines to emulate it.