What about PHP components? Ok, let's create. Part 1. Working with headers.

I do a lot of programming in PHP and every time something starts that doesn't reach the end, and so on. As a result of thinking, I realized that every time I decide to write my own system, framework or something else, I run into a problem. The problem is that I do everything around for the system to work, and not the system itself, or I write too dependent code. As a result, I decided that it was worth taking the time to write only components that will not depend on something personalized, but can depend on each other. This approach is also a bit weird, but still passing an interface to work is better than initializing another class inside a class. For example, for some component it will be necessary to use a database, but we do not know exactly what methods are there, so we operate with our own interface, where we ask to implement a class with such and such a method. Something we have gone from the topic to abstraction.
And so, I began to make my written projects in pieces. As a result, nothing efficient came out, as there were strong dependencies. I had to write again ... The first component that I decided to implement was working with headers. Why exactly he? Because most of the work is built around the communication between the server and the client. And here, just, you need to work with headers.
For all my components, I decided to adhere to the same logic of organizing the file structure: a folder for interfaces, a folder for exceptions, and the class file itself. The folder with interfaces must contain at least 1 interface for the class. There may be no exceptions in the folder with exceptions, because you don't always need to have personal exceptions.

src/
--- interfaces/
--- --- ClassInterface.php
--- exceptions/
--- --- ClassException.php
--- Class.php

Now let's briefly talk about the methods that are available in the class for working with headers.

1. set(array $params)
2. add(array $params)
3. remove(string $key)
4. removeAll()
5. has(string $key)
6. get(string $key)
7. getAll()

I don’t think it’s necessary to give a clear explanation of the methods, but if you are interested, you can look at the GitHub repository. True, now I'm translating my work into English, so don't be too surprised.

And at the end of the part, I want to note that there will be even more classes in the future. I try not to clutter up the post with code, since you can all look at GitHub. You can also download the project from composer packagist.

Comments

[Fabio Politi]

I think that You have encountered typical issues that May rise when you use the language at low level without any frameworks, libraries or even Just patterns.

I am a developer since 20 years now and I can tell you that at the beginning - especially languages such as PHP, now JavaScript - you build your own tools tailored to a specific domain and that Is fine, but It Is not so portable as you May think.

When you are using a framework (a real One such as Ror, laravel, Adonis, masonite, etc.) You are automatically (and sometimes automagically) inhereting well tailored and robust patterns and "solutions" that are engineered by a lot of developers that have struggled against the Same challenges.

Taking a further step I really advice you to look at this: github.com/Mahmoudz/Porto

[Maksim N Epikhin (PIKHTA)]

Moreover, there will be no development in the case of using ready-made solutions. Of course, the result will be better and faster, but it looks like google programmers, stackoverflow gurus and other people who do not know how to solve problems on their own, but only look for answers and copy them.

[Fabio Politi]

Mmm... well... no, but this is just my opinion: believe me, there are no "ready-made solutions" out there, at least for "non-fake-developers" or if You are really developing "something" in order to solve a feat/issue (I've encountered so many peoples that install Wordpress themes/plugins and call themself "developers").

You asked for advices and I am giving some, but You don't have to do what I am telling You, I am just outlinining some points that came from experience:

What I am talking about is at a lower level: if you are using a package manager such as Composer, NPM, Cargo, etc. You are "injecting" a piece of software into your software (that is an approach that even OS - Linux - use very widely).

The package's content is not made by a holy ghost, so You have to always check what it does at its root, or at least have a general idea: it could impact compatibility, security and performance very badly and, from a developer point-of-view, is always worthed checking code made by others, simply because You are always learning or even just stating to approve or reject that package.

On the other hand we WANT/NEED those packages because the process described above it has probably been iterated over and over by other developers that came from different background and different experience.

Every single developer could potentially spot/fix something that the previous creator did not know: the problem is that every developer has his/hers way of building/organizing things that can be productive only for him/her and this - believe me - can be a mess.

That concept may apply at a "code" level (ways of doing a operation by enhancing its performance or readiness) or mostly at an "architecture" level (for example Your solution may work in an Nginx/Apache environment, but what happen when You are using something like Swoole or RoadRunner? and what about containers? tests? code standards?)

Moreover if You are in the loop and see things at higher level, You'll realize that very different "packages"/"frameworks"/"libraries" re-use (or just simply re-write) something that has been first developed in an other language/platform, and that is powerfull because You are not tied to a single language, but You understand the engineering process behind.

For example the frameworks that I've mentioned in my earlier comment were not random (ROR, Laravel, Adonis, Masonite, etc.). If You look at them you'll see that they all use same concepts and even "syntax" of calling things, even if the underlying implementation and language feats is very different: if You came from Laravel and You know what a "migration" or a "seeder" does, You will probably understand the some concept in Adonis (Node) but so other people around the world.

When You use these tools it is your wisdom or experience that tells You the proper way to use a tool (a hammer can't do the work of a screwdriver and viceversa).

It is imperative that before even approaching a package or an entire framework You DO need to know the vanilla language very well (for example real React developers are really good at vanilla Javascript): so I don't think that - on a productive point-of-view - there is such thing like "Laravel developer" VS "PHP developer" and if there is probably someone will "pay the bill" sooner or later.

I simply think that "strictness" (in the code or in the architecture) is there for a reason, and on a long term is very productive, resilient and portable: but there is nothing wrong in writing your own stuff if You feel confident and productive - however is always worthing analyzing how other devs who encountered the same issue/challenge solved or just organized things.

Bye

[Maksim N Epikhin (PIKHTA)]

I understand what you are talking about, but I will tell you so that you should not educate programmers who will not be a php programmer, but a laravel programmer. That is, you say that I should not reinvent the wheel, since there are already all the solutions, and I am talking about the fact that you have to go through everything yourself in order to become a specialist, and not use ready-made solutions. There is nothing wrong with ready-made solutions, it is just that the degradation of a specialist follows their use.

[Maksim N Epikhin (PIKHTA)]

Anyone have any questions, comments or suggestions?