Are we doing it right?

Published: 08 August 2014

Within the last months I looked into other frameworks and other ideas of development. I can't say it changed my mind completely but I see now some things differently. I am developing for the last 10 years or so with PHP, I had always interest in OOP and Design Patterns. I don't think I have written much functional PHP code. I am also deeply involved in Joomla! development and extensions development, I have tried to teach people how to use the framework and what you have to do to make it run with Joomla!

I am really asking myself, if it is the right way we are doing extension development?

Let me give you some context. I checked Laravel a lot and how this framework is doing things. One very good resource is laracast (not a free service but worth any cent). In some of the videos the design of a functionality follows the idea to think about how something behave [1]. It is a way I more and more like and find very useful. If we look at software then we need to make at least two things:

  1. We need to develop the business logic to fulfil a use case.
  2. We need to make it run in an environment.

Usually in Joomla! we use the Model View Controller Pattern (MVC) and we put our business logic into the model. That's fine, that's the way MVC is designed and there is nothing wrong with it. But in Joomla it comes with a price tag. Because we are extending JModelList or something like that we pull in dependencies. For JModelList we have JFactory, JApplication, JCache just to name a few. So we are not able to test in isolation and that makes automatic testing much more complicated.

Wouldn't it be better when we would create for the business logic a separated class tree and inject dependencies? Think about an event extension where we have the need to transform the data we have in an event creating form to the format we need to save it into the database (or any other persistent layer). Almost any Joomla! developer would put that into the Model, in fact that is something I did. For easy transformations I would say it is ok, but if it comes to more complex transformations/business logic then I would go with a separated class. It would allow me to test the transformation/business logic in isolation and with integration tests I could ensure the interface to the framework is still working in the way I am expecting it to work.

I think decoupling business logic from integration code is the future and the way we should go. Anything is going to get more and more complex and when we still stick to a way we created code years ago then we are not going so far. It is an important part of software design to think about the behaviour and for what a class is responsible is for, instead of putting everything in a model.

So the answer is: Yes, we doing it right, but we can do a lot better!

What are you thinking?

[1] Example of TDD in Laravel on laracast

All content is licensed as WTFPL. © 2013