[PHP] Is it really necessary to do OOP?

[vitinho444]

Hello indie-resource !

In the long path to improve my browser based game and knowledge i'm revamping my files and etc.

I have a php file that holds functions that i will use more than once in the game just to be easier on the coding.

The question is, a game like he one in halls tuts or like travian/tribalwars or something, needs OOP? I tried classes as sections for the functions but it doesn't help much..
Till now i did a $variable for each thing i needed.. is it that bad programming?

If yes, how can i make the game more OOP?

[hallsofvallhalla]

OOP is more for readability and usability. You can code it how you want as long as in the end it works and you and anyone you plan to have see the source can understand it. OOP makes life easier by collecting everything and keeping everything in containers for easy use. It is kind of like cooking everything in one pan then separating it later vs cooking everything in separate pans. It tasting good is the end product and it does all go to pone place in the end.

[vitinho444]

OOP is more for readability and usability. You can code it how you want as long as in the end it works and you and anyone you plan to have see the source can understand it. OOP makes life easier by collecting everything and keeping everything in containers for easy use. It is kind of like cooking everything in one pan then separating it later vs cooking everything in separate pans. It tasting good is the end product and it does all go to pone place in the end.

Well yes, i was doing like classes for the Player, City, System etc that hold the functions for each "part" of the game. But i think independent functions work good as well.

[Jackolantern]

OOP has definitely proven itself useful for helping to structure large applications. The problem with relying on functions is that you can't control access to data and functions with functions alone. "Encapsulation", which is the part of OOP that says you don't care how something is implemented provided it gives a public interface to work with it, is extremely powerful. The OOP revolution in the mid-to-late 80's is what really brought about the popularity of libraries.

There really are few application designs that can't be made better with OOP.

[vitinho444]

Well, i didn't quite understood this part :

The problem with relying on functions is that you can't control access to data and functions with functions alone. "Encapsulation", which is the part of OOP that says you don't care how something is implemented provided it gives a public interface to work with it, is extremely powerful.

What i have is functions like this:

Code: Select all

function Redirect($url)
{
	echo '<meta HTTP-EQUIV="REFRESH" content="0; url=' . $url . '">';
}

function ProtectString($string)
{
	$string = strip_tags(mysql_real_escape_string($string));
	return $string;	
}	

function Encrypt($string)
{
	$eText = hash("sha512", $string);
	return $eText;
}	

function Debug($string)
{
	echo "<br>[DEBUG]" . $string . "[DEBUG]<br>";
}

function GetPlayerInfoByName($player)
{
	$playerInfo = mysql_fetch_array( mysql_query("SELECT * FROM `user` WHERE `Username` = '$player'"));
	
	return $playerInfo;
}

[Jackolantern]

What I mean is that you can't protect your own code from accidentally changing something it shouldn't. While it seems stupid and like it doesn't happen ("the only code that will run is the code I write, right?"), but it happens all the time. Some of the most famous program bugs in history were caused by a function or something taking the wrong value and performing its action on it. I don't know if this has specifically happened, but could you imagine if by just a simple slip of the mind, a bank wrote an auto-incrementing routine to increment the bank account balances instead of the time, adding a dollar for every second. In an OOP system, you can hide the bank account balance away, as a private field wrapped up inside of a class. Then you just create properties (or accessor and getter methods) to retrieve it, so that only your controlled methods can change it. In most non-OOP systems, the bank account data would just have to be floating around the program, maybe local to a block, but still, without much control over its access.

OOP is also just great for structuring programs. If you look at pretty much all game engines today, they have an "entity class". Each thing you can interact with in the game is derived from Entity, and they hold inside them their animation logic, their graphic data, their collision logic, their behavior, etc. It keeps it all tied up in one neat package. In procedural game development, you basically have to keep all of these things together manually, oftentimes through naming, such as Skeleton_Animation, Skeleton_Collision_Check, and stuff like that. But they are all just floating around, intermingling with other parts of the program. It also can lead to coupling where parts of the application begin to rely on each other in ways they shouldn't. And once something breaks, it creates a tsunami of other errors and problems that ripple through. It is a pain, it is messy, and it quickly gets out of hand once the game keeps growing.

[vitinho444]

What I mean is that you can't protect your own code from accidentally changing something it shouldn't. While it seems stupid and like it doesn't happen ("the only code that will run is the code I write, right?"), but it happens all the time. Some of the most famous program bugs in history were caused by a function or something taking the wrong value and performing its action on it. I don't know if this has specifically happened, but could you imagine if by just a simple slip of the mind, a bank wrote an auto-incrementing routine to increment the bank account balances instead of the time, adding a dollar for every second. In an OOP system, you can hide the bank account balance away, as a private field wrapped up inside of a class. Then you just create properties (or accessor and getter methods) to retrieve it, so that only your controlled methods can change it. In most non-OOP systems, the bank account data would just have to be floating around the program, maybe local to a block, but still, without much control over its access.

OOP is also just great for structuring programs. If you look at pretty much all game engines today, they have an "entity class". Each thing you can interact with in the game is derived from Entity, and they hold inside them their animation logic, their graphic data, their collision logic, their behavior, etc. It keeps it all tied up in one neat package. In procedural game development, you basically have to keep all of these things together manually, oftentimes through naming, such as Skeleton_Animation, Skeleton_Collision_Check, and stuff like that. But they are all just floating around, intermingling with other parts of the program. It also can lead to coupling where parts of the application begin to rely on each other in ways they shouldn't. And once something breaks, it creates a tsunami of other errors and problems that ripple through. It is a pain, it is messy, and it quickly gets out of hand once the game keeps growing.

Well taking up your bank example, that seems legit but in php the code is unchangeable by the user.. so if i'm coding a system with indie variables they only change where i need them to change..
I know it's hard to get your point, but i somehow understood what you said but i don't see it happen in my code i guess.

[a_bertrand]

As an old programmer I will now appear twisted by answering:
No you don't need OOP to make good code. You can make good code in procedural ways, as well as bad OO too. Sadly PHP is not a good language to do clean OO programming, and I would say they are simply trying to transform PHP in a OO language by doing dirty patches to the syntax.

Where I do agree is, a good OO code will tend to be cleaner and easier to maintain as well as to collaborate with, than a good procedural code.

What is important is a CLEAR idea of what you want to do, and how you want to do it. If you don't, neither a procedural or OO code will be clean as you will hack it till it works. For those cases where you don't know fully how you want the things, be prepared to rework your code MANY times. Don't allow old code which may work but which is a bit hacked. Rework it. That will allow your code to be cleaned over time and will make your life easier. Also try to work in "modules" where 1 piece is responsible of one kind of action or data. Also try to make those "modules" gluable together. If you have such design it will allow you to add new pieces / features without rewriting or hacking old pieces.

[vitinho444]

As an old programmer I will now appear twisted by answering:
No you don't need OOP to make good code. You can make good code in procedural ways, as well as bad OO too. Sadly PHP is not a good language to do clean OO programming, and I would say they are simply trying to transform PHP in a OO language by doing dirty patches to the syntax.

Where I do agree is, a good OO code will tend to be cleaner and easier to maintain as well as to collaborate with, than a good procedural code.

What is important is a CLEAR idea of what you want to do, and how you want to do it. If you don't, neither a procedural or OO code will be clean as you will hack it till it works. For those cases where you don't know fully how you want the things, be prepared to rework your code MANY times. Don't allow old code which may work but which is a bit hacked. Rework it. That will allow your code to be cleaned over time and will make your life easier. Also try to work in "modules" where 1 piece is responsible of one kind of action or data. Also try to make those "modules" gluable together. If you have such design it will allow you to add new pieces / features without rewriting or hacking old pieces.

Totally agree with you, PHP is not easy (not for my goal for now) to make effective OOP.

I can do the same with separated variables and easier than using Classes.

Don't allow old code which may work but which is a bit hacked. Rework it. That will allow your code to be cleaned over time and will make your life easier.

200% agreed, i had a runcron for the resources that was a mess, it was like you said EXTREMELY HACKED, it worked, but it was very ugly to read. We learn from our mistakes right? Since i started 4 years back programming websites i've learnt so many things that help me in next projects.. i can revamp old ones, but doing new ones is always better.

[Jackolantern]

It is true that PHP is not the greatest implementation of OOP. The build-up and tear-down request cycle is somewhat confusing with OOP, and can make you drag along a lot of extra weight in your workflow to heavily use it.

However, it definitely gets better using the MVC pattern (either one you made or a pre-made framework) where you are taking control of the request/response cycle and finally laying it down on an OOP foundation. Then it actually starts to work a bit more the way it should, since each page is a method, and it becomes more logical that your created local objects don't exist in the next request.