Some methods have many parameters. Sometimes they start out like that, sometimes they grow like that over time. Even though a maximum of two parameters is preferable, configuration for a method that does a big thing is difficult. Take curl for example; curl has a lot of options and so several wrappers around curl have arisen to deal with configuring it in a more humane manner. How can we keep the clutter of many parameters as low as possible, while maintaining autocompletion?
This article concludes the series on ProBase module design. It provides an overview of the main parts of the architecture and shows how the previous articles fit in.
I will now address a tricky part of module separation: database queries that access the data stores of separate modules.
An interesting idea: attack the hardness of regular expressions with the power of fluent interfaces.
We found that business logic is such an important aspect of an application that it deserves a special place in the Model View Controller architecture.
At Procurios HQ we have a 'clean whiteboard' policy. That's not an actual policy, but more of a 'best practice'. When working agile, there is a strong tendency to put stuff on the walls. However, as old habbits die hard, quite some people still tend to use magnetic white board to quickly snap a paper schema, a burn-down chart even a whole scrum board on. And that's a shame.
In the first part in this series I mentioned that a business object should not not have a save() function to save itself to the database. It should just have simple getters and setters. This way an object is lightweight and very flexible.
In the first part of this series I handled the module API. I showed that it is a protective shield around the module that keeps it from being bound to other modules. In this part I will put it to work and show how it deals with its dependencies: the other modules on which it depends.
In this series I will explain some of the techniques we use at Procurios to develop software. In our framework, called ProBase, we use modules to partition our codebase. While this is not unusual, in the past ten years we have developed some of our own ways to deal with the complexity of a large codebase. I would like to share this knowledge because we hope it may benefit other projects as well, and we would like to spark your interest in our company: we are looking for enthousiastic developers.