How to avoid the chaos of SRP?

Question

Applying the principle of SRP, you must have many classes. If this works great for a small project, how can you handle and organize the number of classes in a large project?

• How to organize the folder structure?
• how do you remember what you are building?
• how do you know if others have not built the same functionally in another class?

Answer 1

This applies to all types of libraries. Not just SRP.

Organizing classes / functions can be a headache, but there really are just a few things you need to keep in mind.

• Plan.
• Define and save the correct convention name for files, classes, folders, methods / functions and variables.
• Break your classes into namespaces or, at least, into subfolders of the main muscle groups of the system.
• Document: internally (good comments, file headers, and the public method lists) and externally (wiki, readmes, excel, something)

By 2, I mean: /library/muscleGroup/useType_nameOfClass.php for files / folders where useType is something like "factory" "abstract" "data / dto" or any templates that you use. Then in each file the class should be the same as nameOfClass, and each method name should strictly follow the pattern. [Action][on what][with what conditions] and save the list of actions and "what" and stick to their RELIGION.

Do this and you won’t be able to duplicate functionality, as you can easily find the classes and methods you need for the things you want. Because they have logical names like Get_User_ById and Get_Transactions_ByNewest or Combine_Ingredients_FromRecipes .

This last one may contain the comment above:

 // Combines many recipes into one ingredient list // $recipes = an array of recipe objects // returns an array of ingredient objects with their correct quantities 

---

List of example actions: (should be fairly general and apply to any application)

• Receive
• Set
• Delete
• Move
• Combine
• Combine

Sample list "On": (must be a specific application)

• User
• Ingredient
• Recipe
• Measurement
• Resolution
• Mark
• Ad

Answer 2

It depends on the project, but if it was something that has a lot of CRUD without significant business rules, I would choose a simple structure with script files to support this solution. I have done this in the past, and it is very fast, but slowly changing. Usually Eric Evans is called an anti-Smart UI pattern:

"Put all the business logic in the user interface. To grind the application into small functions and implement them as separate user interfaces, implement business rules in them. Use the relational database as a general data repository. Use most automated user interfaces and visual programming tools available [ Evans p .77]. "

If you are doing something with a lot of real business rules and have more time, or you expect it to have a long life:

• Find out the tasks of the system and try to implement these tasks as teams of a higher level.
• If these higher-level commands manage the lower-level base classes and are called from ui. I use the Zend Framework, and I have controllers that call these high-level commands, but in most cases it is too much. For me, these classes are stored in the application folder, divided into a module (accounting, email, etc.).
• The lower level classes are stored in the "Domain" folder, which is also divided into the same modules as the "Application" folder. Domain classes represent the objects that it is working on (Email, ClassCredit). They are small and perform only those tasks that make sense for this concept.

As for resources that will help you in the future, Clear the code from Bob Martin and Domain-Driven Design (no other link can post) Eric Evans. Both books are brilliant and offer tactical and strategic steps, respectively, to solve this chaos.

Answer 3

Folder structure

The Zend Framework organizes its classes by functionality and names them as such. For example, the Zend_Controller_Action_Helper_AjaxContext class is located in /library/Zend/Controller/Action/Helper/AjaxContext.php .

This serves two purposes: the organization of folders and the logical separation of functionality. You always run into the problem of “remembering what you are building,” but by using SRP and placing functionality where it is logically “the most correct”, you can be confusing.

IDE

When working with many classes, an IDE is required. Shortcuts that allow developers to quickly find classes, file names, and methods anywhere in the project deal with thousands of classes that are almost trivial.

Using the same example as above, you need to be able to find the class in various ways:

• Search for a class name. In EclipsePDT, it is as simple as ctrl+shift+T to search for classes (types). (note: I honestly don't know if this is a feature of the eclipse or the addition of PDT plugins).
• Similarly, you can search by file name using ctrl+shift+R (resource).
• Or a method inside the ctrl+shift+m class