Oop also leads to a big files/instances spread. So if yiu return to your code in a year, I guess the first "ugly" one file code will take a couple minutes to get you an idea what's going on. But classes will take much more time to track all dependencies across files. So not every solution needs oop in it of course
Thanks for the feedback. But I don't think I will write the code this way in production. Instead of putting this in one file. Each class will have its own file.
Though these classes don't have dependencies even if they have, tracking them is easier in modern editors/IDEs.
Based on the feedback I think you might go with a functional approach which is also a good tradeoff.
In our production, we do not choose only one approach. As I mentioned, every method has its pros and cons. And OOP approach for fast/draft release is a tortoise. For this purpose, we, of course, use functions.
Programming is about learning and using instruments for their purpose not to choose only one tool to rule them all :)
And of course, refactoring is a big drawback lately, but it is an excellent teacher. You will never write perfectly from the first time, but you should learn how to write the first time to get your app working and don't spend on it a year
At my end, it is mostly OOP. I started with procedural then later joined the OOP approach. I would love to see how different approaches are combined in one project. In your free time, you should enlighten me about that. Let's talk.
I quit PHP dev three years ago, last stuff we made was a super simple MVC framework to build a simple protected stacks [auth/reg/acl/db/pages].
So OOP is used for:
base Db instance (so a developer can switch between Mongo/Postgres/Mysql). And yes, of course, many ORM libs solve this problem, but we had a team, that must start developing "yesterday" and they well experienced in raw SQL, Mongo data queries and didn't have time to learn new instruments.
Acl. But it is super simple, not extendable and used just to save its state.
Controllers. This is the most advanced part, they are good extendable and give some flexibility in Controller-Action (also Security, Templating, i18l etc.) And this is just a couple Classes/Interfaces
Any API, other Models are easy to declare in only one folder and you ready to use it anywhere
And most of the work is done by functions:
Init state of the app
working with sessions
autoloading
any repeatable data manipulations
etc
So an example of prototyping. This project, of course, is a mess for OOP programmer, everything can be refactored to OOP if needed and gain more complexity.
So one of these panels needed in automatically logging everything, that happens under the hood. So in just 10 minutes, my colleague wrote a solution directly in init function, that grabs data from the controller and write everything in file. He could create a Log interface, think of logging not only in a file, extend it and create FileLogger. Create some hook for middleware in init app, extend some base middleware model and then log there and spent on it from 1 hour to 2 days, because in that way some code could not work correctly and some part of the engine must be rewritten.
Now, when this thing is working for a year, they want to connect all the panels to Grafana, so they refactored code and did this part in OOP and can send data anywhere they want.
OOP is excellent and solves many problems, but when the language allows you to save your time, write faster and more productive, why not using it?
And you know, this OOP-function skeleton of 2MB still serves its purpose and allows to create fast panels.
This is actually something we’ve discussed heavily at places where I’ve worked. Usually implementation like this makes it harder to read (which is interesting considering the arguments for SOLID are maintainability). I’ve seen these patterns beneficial in libraries to be consumed and projects that are a massive scale where design principles help with on-boarding. For smaller things, seems like overkill.
Oh yah this isn’t a dig at the authors post at all. Much can be gleaned from applying design principles to a simple problem for education sake. I was commenting on design patterns in general. They are another tool in a developers toolbox, nothing more. The article did a great job of highlighting one of the SOLID principles.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Oop also leads to a big files/instances spread. So if yiu return to your code in a year, I guess the first "ugly" one file code will take a couple minutes to get you an idea what's going on. But classes will take much more time to track all dependencies across files. So not every solution needs oop in it of course
Thanks for the feedback. But I don't think I will write the code this way in production. Instead of putting this in one file. Each class will have its own file.
Though these classes don't have dependencies even if they have, tracking them is easier in modern editors/IDEs.
Based on the feedback I think you might go with a functional approach which is also a good tradeoff.
In our production, we do not choose only one approach. As I mentioned, every method has its pros and cons. And OOP approach for fast/draft release is a tortoise. For this purpose, we, of course, use functions.
Programming is about learning and using instruments for their purpose not to choose only one tool to rule them all :)
And of course, refactoring is a big drawback lately, but it is an excellent teacher. You will never write perfectly from the first time, but you should learn how to write the first time to get your app working and don't spend on it a year
At my end, it is mostly OOP. I started with procedural then later joined the OOP approach. I would love to see how different approaches are combined in one project. In your free time, you should enlighten me about that. Let's talk.
I quit PHP dev three years ago, last stuff we made was a super simple MVC framework to build a simple protected stacks [auth/reg/acl/db/pages].
So OOP is used for:
And most of the work is done by functions:
So an example of prototyping. This project, of course, is a mess for OOP programmer, everything can be refactored to OOP if needed and gain more complexity.
So one of these panels needed in automatically logging everything, that happens under the hood. So in just 10 minutes, my colleague wrote a solution directly in
initfunction, that grabs data from the controller and write everything in file. He could create a Log interface, think of logging not only in a file, extend it and create FileLogger. Create some hook for middleware ininitapp, extend some base middleware model and then log there and spent on it from 1 hour to 2 days, because in that way some code could not work correctly and some part of the engine must be rewritten.Now, when this thing is working for a year, they want to connect all the panels to Grafana, so they refactored code and did this part in OOP and can send data anywhere they want.
OOP is excellent and solves many problems, but when the language allows you to save your time, write faster and more productive, why not using it?
And you know, this OOP-function skeleton of 2MB still serves its purpose and allows to create fast panels.
This is actually something we’ve discussed heavily at places where I’ve worked. Usually implementation like this makes it harder to read (which is interesting considering the arguments for SOLID are maintainability). I’ve seen these patterns beneficial in libraries to be consumed and projects that are a massive scale where design principles help with on-boarding. For smaller things, seems like overkill.
The easier solution is in the article he mentioned: itnext.io/fizzbuzzbazz-how-to-answ... (String Concatenation).
Oh yah this isn’t a dig at the authors post at all. Much can be gleaned from applying design principles to a simple problem for education sake. I was commenting on design patterns in general. They are another tool in a developers toolbox, nothing more. The article did a great job of highlighting one of the SOLID principles.