DEV Community

loading...

Discussion on: FizzBuzz Refactoring Challenge with Open/Closed Principle

Collapse
mrspartak profile image
Spartak

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

Thread Thread
olivermensahdev profile image
Oliver Mensah Author

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.

Thread Thread
mrspartak profile image
Spartak

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.