Functions vs OOP

[SchweppesAle]

Hi, I'm currently working on a system which includes a huge mass of php files in order to make their functions available to the rest of the system.

 

Was hoping you guys could give me a few persuasive arguments/examples as to why we should instead lump these functions together into classes.

 

Basically, this is a "Is the juice worth the squeeze" type question. 

 

Thanks

[SchweppesAle]

I guess this title was a little off "Function Oriented vs OOP" would sound more appropriate

[KevinM1]

OOP is far more than stuffing similarly themed functions into classes.  If that's all you're aiming to do, classes won't be of any more benefit than generic procedural library code.

[SchweppesAle]

OOP is far more than stuffing similarly themed functions into classes.  If that's all you're aiming to do, classes won't be of any more benefit than generic procedural library code.

 

Actually my aim is to do it correctly.  I was hoping someone could point a few key benefits involved in redesigning the system so that it's more Object Oriented as opposed to a "procedural library".

 

Encapsulation for example is one of those concepts which I feel that I practice without fully understanding. 

 

class someObject{
private $_value;

function doAnOperation(){
/*do stuff*/
return $this->_value  = $returnValue;
}

}

 

vs

function doAnOperation(){
/*do stuff*/
return $returnValue;
}

 

what did I gain by doing it the first way, etc?

[oni-kun]

what did I gain by doing it the first way, etc?

 

You can instantiate the class, use it with a controller, add a constructure to fill in the internal variables.

 

But from what you posted, you will gain nothing in efficiency or ease of maintainability.

 

[roopurt18]

Functions perform operations.  Objects define behavior.

 

See my responses throughout this thread for an explanation of what I mean:

http://www.phpfreaks.com/forums/index.php/topic,284048.msg1346916.html#msg1346916

 

(And more specifically, this response and on: http://www.phpfreaks.com/forums/index.php/topic,284048.msg1347796.html#msg1347796)

[SchweppesAle]

what did I gain by doing it the first way, etc?

 

You can instantiate the class, use it with a controller, add a constructure to fill in the internal variables.

 

But from what you posted, you will gain nothing in efficiency or ease of maintainability.

 

 

ok...let's try again then

 

class someObject{
private $_value;
private $_someArgument;

function __construct($argument1)
{
$this->_someArgument = $argument;
}

function doAnOperation(){
/*do stuff, use $this->_someArgument*/
return $this->_value  = $returnValue;
}

}

 

vs

 

function doAnOperation($someArgument){
/*do stuff*/
return $returnValue;
}

 

sorry if I'm coming across as hardheaded.  I just really want to have solid understanding of these concepts

[oni-kun]

"I'm currently working on a system which includes a huge mass of php files in order to make their functions available to the rest of the system."

 

As roopurt explains, it all depends on what you're wanting to do with it. If not all the packages I've seen on OO projects keep predefined functions within a functions.php to be included, they don't waste class space for things that don't really require classes.

 

If you're wanting to create a jumbled class of functions then you should re-work your logic.

[SchweppesAle]

Functions perform operations.  Objects define behavior.

 

See my responses throughout this thread for an explanation of what I mean:

http://www.phpfreaks.com/forums/index.php/topic,284048.msg1346916.html#msg1346916

 

(And more specifically, this response and on: http://www.phpfreaks.com/forums/index.php/topic,284048.msg1347796.html#msg1347796)

 

Looks like a solid implementation of the MVC design pattern. 

 

Say I had a controller which simply includes all files within a "generic procedural library" and used them as a model though. 

 

I would still be able to perform any necessary operations from within the model and then retrieve data which would then be passed over to the view. 

[SchweppesAle]

"I'm currently working on a system which includes a huge mass of php files in order to make their functions available to the rest of the system."

 

As roopurt explains, it all depends on what you're wanting to do with it. If not all the packages I've seen on OO projects keep predefined functions within a functions.php to be included, they don't waste class space for things that don't really require classes.

 

If you're wanting to create a jumbled class of functions then you should re-work your logic.

 

It's really not my project to begin with.  I'm just picking up where someone else left off.

[roopurt18]

I would still be able to perform any necessary operations from within the model and then retrieve data which would then be passed over to the view.

Yup, you sure would!

 

[SchweppesAle]

I would still be able to perform any necessary operations from within the model and then retrieve data which would then be passed over to the view.

Yup, you sure would!

 

 

so it really doesn't matter? 

[KevinM1]

Remember: the currency of OOP is objects, not classes, methods, or functions.  What are objects?  Instances of a custom data type you create.  What is a data type?  Data and the operations that can be performed on that data (example: an integer represents both a counting (i.e., non-decimal) number and the operations that can be performed on that number - addition, subtraction, multiplication, and division).

 

Objects are designed to be black boxes.  Their internals shouldn't matter to other coders, or even the system at large.  All that's required to use an object is knowledge of its public interface (its publicly available methods and data members, which is not the same as the language construct named 'interface').  Separating the internals from the public interface is known as encapsulation, and is a cornerstone of OOP methodology.  The objects shouldn't know or care about the main script they're being used in.  Similarly, the script shouldn't care about how an object does its job.

 

Why does all of this matter?  Encapsulation, along with polymorphism and inheritance, allows objects to be flexible.  They can plug into and mix with other objects with little difficulty if designed correctly.  These combinations of objects create subsystems, which, in turn, create entire applications.  It also promotes code reuse.  You can lift entire subsystems from one project to put in another without having to rewrite a single line of code because the objects aren't tied to the system that use them. 

 

It's programmable LEGOs.  You design the bricks (color, thickness, size, number of holes), and then you can assemble them in a variety of different ways depending on what you need to do.  These bricks represent a membership system.  These other bricks represent the database.  And these represent command objects that act on the system in different ways depending on HTTP request info.

[JonnoTheDev]

Actually my aim is to do it correctly.  I was hoping someone could point a few key benefits involved in redesigning the system so that it's more Object Oriented as opposed to a "procedural library".

Getting your head around OOP is difficult if you have been creating procedural code for a long time. The first thing you need to get your head around is that objects should be modelled on real-world items. What parts of your system fall into this category? i.e a User. A user is a person, a real-world item. What can a user do and what attributes do they have? Well, they have a name, an age, they can perform tasks such as logging in to a website, etc.

A user object has no ties (coupling) with other parts of the system. There are no database ties, no usage of functions that have to be coupled in with the user class, etc. So, in effect I could take this user object and re-use it in any other system that has users. If another system has different types of users lets say admins I can extend the user class with lets say adminUser. This will give me more functionality for an admin user.

Read the following on the php freaks tutorials

http://www.phpfreaks.com/tutorial/oo-php-part-2-boring-oo-principles

[ignace]

OOP is based around four basic principles: abstraction, inheritance, encapsulation and polymorphism.

 

Nightslyr has already done a great job explaining these

 

Objects are designed to be black boxes.  Their internals shouldn't matter to other coders, or even the system at large.  All that's required to use an object is knowledge of its public interface (its publicly available methods and data members, which is not the same as the language construct named 'interface').  Separating the internals from the public interface is known as encapsulation, and is a cornerstone of OOP methodology.  The objects shouldn't know or care about the main script they're being used in.  Similarly, the script shouldn't care about how an object does its job.

 

Besides these four principles there are principles which are considered good-practice and carry the mnemonic name SOLID (http://en.wikipedia.org/wiki/Solid_%28Object_Oriented_Design%29)

[roopurt18]

I would still be able to perform any necessary operations from within the model and then retrieve data which would then be passed over to the view.

Yup, you sure would!

 

 

so it really doesn't matter? 

 

When you get right down to it, no it doesn't matter if the code is OOP or procedural.  There are plenty of great programs written in either or both.

 

Regardless of OOP vs. procedural, you still have to write the code that validates the data.

Regardless of OOP vs. procedural, you still have to write the code that saves the data.

Regardless of OOP vs. procedural, you can still obtain encapsulation.

Regardless of OOP vs. procedural, you can still obtain inheritance (although it will require more procedural code since it's not "built-in")

Regardless of OOP vs. procedural, you can still enforce behavior (although it will require a lot more procedural code than OOP code)

 

When you want to design, enforce, and extend behavior, use OOP.  You don't use OOP to write behavior because it's impossible to do so in procedural code, because it is possible.  You do it with OOP because that's what it was designed to do so it has better facilities for doing so.

[SchweppesAle]

Remember: the currency of OOP is objects, not classes, methods, or functions.  What are objects?  Instances of a custom data type you create.  What is a data type?  Data and the operations that can be performed on that data (example: an integer represents both a counting (i.e., non-decimal) number and the operations that can be performed on that number - addition, subtraction, multiplication, and division).

 

Objects are designed to be black boxes.  Their internals shouldn't matter to other coders, or even the system at large.  All that's required to use an object is knowledge of its public interface (its publicly available methods and data members, which is not the same as the language construct named 'interface').  Separating the internals from the public interface is known as encapsulation, and is a cornerstone of OOP methodology.  The objects shouldn't know or care about the main script they're being used in.  Similarly, the script shouldn't care about how an object does its job.

 

Why does all of this matter?  Encapsulation, along with polymorphism and inheritance, allows objects to be flexible.  They can plug into and mix with other objects with little difficulty if designed correctly.  These combinations of objects create subsystems, which, in turn, create entire applications.  It also promotes code reuse.  You can lift entire subsystems from one project to put in another without having to rewrite a single line of code because the objects aren't tied to the system that use them. 

 

It's programmable LEGOs.  You design the bricks (color, thickness, size, number of holes), and then you can assemble them in a variety of different ways depending on what you need to do.  These bricks represent a membership system.  These other bricks represent the database.  And these represent command objects that act on the system in different ways depending on HTTP request info.

 

That entire paragraph starting from - "Objects are designed to be black boxes". 

 

Huge - thanks a lot man.  I think I'm finally starting to understand.