Hi I’m writing my own high level API of Amazon’s PHP SDK which is used to manipulate DynamoDB, a nosql database.
I find myself writing roughly 150 lines of code for a single function that does one operation, including error checking, request building and of course, comments. If I keep going this way the API class can easily exceed a thousand lines, which I think is a bit hard to maintain.
Thus I’m thinking of breaking my class down into several smaller classes, each handling a set of operations. Say like, table operations, item operations, and batch operations. But I’m not an expert with software design patterns, so is this really a good way to modularize? Or is there any design pattern that I should comply and make my code easier to maintain?
Your question is a bit subjective, since you do not provide the code so that we can see what you’re trying to accomplish in fact.
But yes, you need to separate your classes into smaller components, each one with its own responsibility. There isn’t a single pattern that tells how exactly to do that, but the Single Responsibility Principle is a good one to start with. It’s about separation of concerns.
You said:
There you go, separating error checking, from request building, and then separating it again into smaller components, each with just one responsibility. You must have just one reason to change each component, never more then one. You must have a clear domain model defined, with dedicated services for each one of these domain objects.
Take for example, the answer of @teresko here:
How should a model be structured in MVC?
So, bear in mind that you need to separate your application into layers. The request is part of the presentation tier. Which in modern MVC-alike apllications is composed by the Controller Layer and the View Layer, which interacts with the Model layer in order to prepare the presentation for a given request.
See: http://martinfowler.com/eaaCatalog/