Start with OOP using classes as a set of methods?

Question

Is it possible to start with object oriented PHP using classes as a set of methods? Are there any flaws with this approach?

I know that OOP is much more than that, but my PHP projects are too small to use everything that OOP has to offer. On the other hand, my projects are getting too large to be updated / maintained with procedural programming only.

I read a lot of topics about OOP, and from time to time someone says: “OOP is more than just a collection of functions” (or something like that). It made me think: it might be true, but it could also be my chance to finally plunge into the world of OO programming by doing just that.

So, is this a smart first step to actually start using and exploring OOP? Or are there serious flaws that I need to know about?

Answer 1

Your question is very large, but it deserves a simple answer that you can remember and keep with yourself as you continue your journey into the world of object-oriented analysis and design (OOAD).

So, is this a smart first step to actually start using and exploring OOP? Or are there serious flaws that I need to know about?

As you can imagine, we cannot directly answer this question. What is smarter and what does not depend on our own abilities. For instance. for some people, this may be wise, because it helps them stop mistakes early, and that's the way to go. For others, it can be a complete desaster, because they do not detect any errors, continue to develop software, because they think: if I do not see the error, this is completely correct.

So how to solve this dilemma? Easy, we have two parts in OOP that you can easily recognize and keep with you. The first is called STUPID - you can imagine what it means if something falls into this category, and the second is called SOLID , and it is also self-telling how to relate to something there.

• So don’t be STUPID, take SOLID.

Answer 2

Disclaimer: I did not deal with php after a while, so my syntax may be incorrect.

The term OOP is a little fuzzy imo, which means that different people will think about slightly different things when they hear it, so do not confuse it when you hear conflicting things about it.

Structuring such functions with classes will not hurt your code, but then you simply use classes as namespaces for your functions. Usually you need to define classes in such a way as to encapsulate any aspect of your system, which means that only the code of this class will deal with this aspect directly, and everyone else simply uses this class.

For example, you might have a class that manages the print job queue. If you have any code that wants to print a document, it does not need to know how and where jobs are queued or how they are sent to the printer, it only needs to know the print queue object (call it $jobQueue ), which can have a method like $jobQueue->enqueue($document) .

Now you can say: "In this code, you could use the global function enqueueJob($document) ", and this is true until you want to have more than one queue (for different printers) and queues that work differently (store jobs in the database, in memory or not at all - imagine a queue that goes directly to the recycling bin :)). With OOP, this scenario is not a problem, and these details are completely hidden from the code that the document wants to print - all he needs is that it has a job queue object using the enqueue method.

To get this “interchangeability” of job queues, they must have a common interface (in this case, the enqueue method) that must be carefully chosen to cover all the needs of code that wants to print things, but without making too many assumptions about print queue is running. For example, you can imagine that the enqueue method takes a file path as an argument that tells the queue where to store its files, but this interface would be useless for the queue that runs in the database. This is the art of finding good abstractions.

Now, to get back to your original question, simply hiding related functions in a class is, in my opinion, not OOP, as long as there is no thought about what abstractions / interfaces a new class should provide. Without this, all the code that this new class uses will be tightly bound to it and will need to be changed / revised if you ever decide that you need a different type of print queue. :)

However, "not OOP" is not the same as "not a good idea." I say, follow him and reorder your functions. In my opinion, it is important to keep in mind that not everything should be an object or correspond to some abstraction. But maybe you will find out that you have some functions that perform similar things (a queue in a file, a queue in a database) that can be abstracted to a common interface.

Answer 3

OOP is just a collection of methods. But thinking in programming is different. In classes, you encapsulate similar functionality. The code is more readable, you do not need to write the same functionality again and again. It is also safer (private members) if you are writing a library, the end user can only change what you want, etc. Therefore, I do not recommend trying to bypass OOP with a set of functions and use a real OOP instead. There is no reason why not.

Answer 4

I do not recommend it, you will get used to writing procedural code disguised as OOP, which you do not want. It can be difficult at first, but study OOP with all its functions, read about templates, emphasize coding standards and, most importantly, study applications with an object-oriented architecture.

Answer 5

Some things are functional, procedural, and object-based. Use the one that is most suitable for this circumstance. You will not be mistaken in this philosophy.

Answer 6

Since this question is not related to php at all, but to OOP in general, this answer should be valid for many languages.

There is another pattern in OOP. I suggest reading about the "gang of four." This is a really good book that explains some of the simplest patterns you can use when running OOP.

Instead of using a class to store sets of a static function, you should consider storing all your functions in a namespace.

Classes often define objects (for example, a physical object). Any physical object has a set of properties and behavior.

When designing a class, you try to define these behaviors and properties. For example, a bag.

 class Bag: // Methods function open: ... function close: ... function empty: ... function add(item): ... // Properties array items: [] bool is_open: false 

Some properties or method may be hidden or visible to the world. In my example, you can make the add throw function exclude whenever you try to delete or add an object to a closed bag. Clearly, all the methods here are related to the real object.

Adding methods or attributes that are not associated with the bag must belong to a different namespace or class. It really depends on what you are trying to do.