Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

MrOldham101

New Coder
Context:

I am a professional full-stack web developer currently working on a medium to large scale web app. The system is developed mainly in PHP and we have adopted a very procedural style of coding using large repositories for each "module" of our system that contains all the functions related or required for that module.

So far this approach has allowed us to release large new features extremely fast as we do not have to think about what the data may look like in the future (like in OOP) we just deal with the data we have right now and make changes as and when required.


Issue:

As we have expanded so quickly our app has quickly become spaghetti code that is getting harder and harder to maintain and develop on. For example, we might have a function to edit an entire user and then another function just to update their permission and if we wanted to add some sort of validation or check to see if they can actually edit a user we would have to go round the system trying to find all the functions where the user is updated and add the validation call to each one which you can imagine is very error-prone. To solve this we are currently undergoing a major restructure converting our procedural style code into Object-Oriented Code.

In restructuring to an OOP style, we have actually found that a lot of our previously simple concepts have become massively over-complicated when written as objects and although the files are much smaller and have a single responsibility, They are seemingly just as hard to maintain due to how many objects and methods have to be instantiated just to achieve what we used to do in one function. This leads me to believe that the new OOP code is also much less performant as we are having to do so many extra things such as instantiate an array of objects when we might only require one property from each.


Research:

I did quite a bit of research trying to figure out where we were going wrong. I understand PHP is not the best language for OOP however we were still not seeing much of the many benefits people rave about when talking about OOP. To my surprise, I actually found a lot of people having similar issues and a growing community of developers discouraging the use of OOP for some extremely valid reasons.

This is what led me to start researching alternatives and how they stack up against each other which is when I came across Data-Oriented design. From what I can gather, this style of programming has only really been used in the gaming industry however it boasts being ultra performant, very easy to read and does not rely on you having to know what your data may look like in the future. As I read more into it, it seemed to combine the things I love about procedural code with the organisational benefits of OOP however there is just not enough examples out there.


Question:

So given the following pseudo example:

An example user repository


class userRepository { //database class public $db public function __construct($db) { $this->db = $db } public function getUser($fields, $id) { $query = "SELECT $fields FROM user WHERE id=$id" $result = $this->db->query($this->db->link, $query); return $result->fetch_all(MYSQLI_ASSOC); } public function addUser($data) { //code for adding user } public function editUser($data) { //code for editing user } public function editUserPermission($data) { //code for editing a user permission } public function checkUserCredentials($data) { //code for checking user log in credentials } // (lots more functions for anything to do with a user) }

an example holiday repository

class holidayRepository { //database class public $db public function __construct($db) { $this->db = $db } public function getHoliday($fields, $id) { $query = "SELECT $fields FROM holiday WHERE id=$id" $result = $this->db->query($this->db->link, $query); return $result->fetch_all(MYSQLI_ASSOC); } public function addHoliday($data) { //code for adding user } public function editHoliday($data) { //code for editing user } public function addHolidayBulk($holidays) { foreach($holidays as $holiday) { $this->addHoliday($holiday); } } public function getListOfAllHolidaysForUser($iduser) { //code for getting a list of holidays and joining on to the //users table and the holiayType table to also get the extra data //that is displayed along side the holiday } public function getAllUsersThatHaveHolidaysBetweenDates($start, $end) { //code to get all users that have holidays within a given period } // (lots more functions for anything to do with holidays) }

Keep in mind that the holiday repository may often join onto the user table, and it may also use more than just the holiday table such as a holidayType table, so long as it is used within the holiday "module". This happens an awful lot in all of our repositories where data from another table/"module" is required and we struggle to figure out which repository the function should live in. It always ends up going in the repository the context of the request is in. For example, a function for getting all of the users that have holidays within a set of dates would be a function within the holiday repository.

I understand a lot of people will find the example pseudo-code a bit alien and will want to criticize it.


Could someone give me an example of how this procedural style of coding where you essentially write a function for what you need to do to data as and when you need to do it and then just group it by which feature of the system it is for, would be written in an Object-Oriented Style and a Data-Oriented Style and explain what the benefits/drawbacks are?
 
In terms of paradigm there's been Aspect Oriented Programming (https://en.wikipedia.org/wiki/Aspect-oriented_programming) that's been floating around for a while, but I don't know if I've seen it in practice.

I don't think answering this question in any way would provide any significant insight to the benefits of any of the programming paradigms. I think trying them out and evaluating the experience of using the different paradigms is the only way to go, and that only comes with time. I think with any programming endeavour, you will always need to evaluate how the execution of the development of a software project is proceeding or has gone.
 
Recently I noticed a movement towards modular methods in OOP in languages like GO or Rust, in contrast to Java classes conglomerate. I have to make myself learn a bit of those languages, they seem to [UWSL]have taken root among programmers.[/UWSL]
 
I think it depends on the size and scope of the software you'll end up writing. Java, C# and C++ tend to end up in applications where you're looking for "control" over a broad depth of an application and the application is "large": possibly from a low level like network communication to a higher level such as a user interface. I guess for certain types of application you can handle that range with a single language (with relevant libraries), or you can break it up into smaller pieces - I'm thinking like how you have ReactJS/Javascript/GraphQL/HTML/CSS, which are all kinda separate "languages" and all focus on different aspects of an application. The OOP languages definitely have a framework overhead (many classes/interfaces interacting with each other in many ways) but that framework starts to pay off the larger an application gets. You (or at least I do) can start thinking of the framework and the components that OOP gives you as "black boxes" and focus on smaller parts of an application at a time - but this all depends on how you plan and structure the project from the beginning. It just takes practice and reflection.

This also highlights that there are different languages that are targeted for different purposes: I don't think you would ever want to consider one language as a general purpose language. From most of the languages I've encountered so far at the basic level it is procedural - except for Haskell and Miranda, but I won't go there for now.

I feel like I should add something like "But what about the linux kernel? That's all C and procedural right?" ... maybe later.
 

Buy us a coffee!

Back
Top Bottom