PHP Software Architecture Part 4: Refactoring

Sameer Nyaupane
4 min readOct 31, 2017

--

All right. Let’s go over and refactor our code from part one.

Let’s once again look at our FlightController:

First of all let’s move saveData() into a Repository class. It’s easy since all the Database related code is in this method. For your own code base, if you do not have a separate method, we would have to do that first. This makes it easier to move it into a different layer.

Now this is our FlightRepository class:

All we did was move the “saveData” method from the controller to its own separate class.

For the “log” method, we will move it into a Service class. This is because we may need to reuse this log functionality in another place too. So it is a wise choice to move it into a Service class.

This is how our FlightLogger Service will look like:

Now, finally we move all our Flight API call logic into an Adapter class.

Note that we are also injecting the FightLogger Service instance to this Flight Adapter. Laravel auto injects dependencies, so we won’t need to inject them manually.

Finally, this is how our Controller looks:

As you can see, we are down to just one method now. Which is much better from our previous four methods for a single functionality. Now there is one more step to make this remaining method lean. Let’s introduce a Domain class to contain the remaining logic.

This is how the Domain class looks like:

Now, let’s refactor our Controller once again.

This is how the FlightController looks:

And, there you go. Our FlightController is very thin. And it does not contain any business/domain logic at all. We moved all our code into different layers. We used Domains, Repositories, Adapters and Services to get to the Extensible Architecture.

— UPDATE— — — — — — — — — — — — — — — — — — — — — — — — — —

Since I wrote this article series, I’ve got an article as a reply from Mantas Dani . Here is the link to the article: https://medium.com/@mantasd/refactoring-refactored-code-d54e801001b4 . Now talk about a long reply, haha. But I’m happy he went over and wrote it.

So, let’s give him a reply too. Time to break it down. He argues that the Domain and Repository layers are not needed for this simple functionality. And he goes over a simpler approach to the same code refactoring process that we did in this part (Part 4). I kind of agree with him, if all the code we write is done here, then it is enough to keep it in the Controller that way. But our boss is not done yet. He is surely going to demand more from the application. That is why we have a Domain layer to keep things easier when we introduce new code. The Domain layer is not compulsory, and you can introduce them as needed. Same thing for other layers. Originally the “getFlightAvailabity” method is much more complicated, with Factory pattern, and Translator layer added on top of it. This is because I had to have a common interface between three different Flight APIs, for better code reuse. That is why I have the Domain layer. And I have the Repository layer because I use the same calls from other methods in the code. Also he talks about writing tests. The original code did not have test for this functionality at that time. But I was refactoring towards it, so hence the dependency injections. And yes if we are not testing the code, we can just call it statically like he does in his example. Again, I agree with that. But since I was actually planning to come out with a brand new testing series, I thought I’d include the dependency injections before hand.

I recommend you to check out his article for a different approach to refactoring the same code. No harm in doing it a different way, if that fits our use case, eih? ;) I believe we should be open to new ideas and approaches as programmers. And hopefully even learn something new from those experiences.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

I hope you enjoyed the series. Please don’t forget to give some “claps” here on Medium.

PS. I will be writing a brand new Test Driven Development series as stated above. So, please subscribe for more to come!

Happy coding! Cheers :)

Check out my other series at:

--

--