On Modularity and Separation of Concern
This is a hastily written diatribe that was prompted out of frustration. It’s mainly focused on Java web application development but applies to all software development.
Ability to swap, exclude chunks of functionality or features without any effect on remaining architecture or application. Each module is independent of each other. Shared resources can exist between modules in separate jars
- Allows full flexibility for custom builds. Depending on customer some features can be included while others excluded
- New features can be added regardless of rest of the application
- Easier maintenance. Problematic section can turned off, replaced without effecting rest of application.
- Vendors and technology changes can be done on limited basis
Separation of Concern
Every area is responsible solely for the area to which it is assigned. This concept starts at the macro level and works it way down to the micro influencing the full gamut. At the macro level, there are very distinct layers, each with it’s own concern. The start of this is the tried and true MVC design pattern. These layers still fit into the traditional three-tiered system with some more fine graining distinction.
- Model- objects that the view act upon
- View or Presentation- the visual interface that the users see
- Controller- Responds from views and provides data to view
- Business layer- Provides all business functionality
- Data Access- Intermediary between DB and the rest of application
- Data Storage- Stores the data for efficient recall
On the micro level this concept affects every web page, and every java class, and every DB table. This greatly increases coded reuse, saves developer time, and reduces bugs.
- JSP (or an alternative) should not have any business logic inside. Its only area of concern is to provide a view to be displayed
- HTML should not be concerned with layout, style, or interactions. It area of concern should be solely for structuring data.
- CSS should handle page layout and style
- Java classes should represent a single object, or series of related procedures. Name should reflect its purpose
- Java methods should be kept very short, each responsible for a single thing. Meaning that there will many small methods each responsible in place of long unwieldy methods that are difficult to maintain and difficult to extract or overwrite. Concept of least surprise. Methods should not effect areas outside of its stated purpose in the method name.
- Database tables should be normalized with each table representing a single thing. This keeps table size down, makes queries faster and more understandable and prevents data repetition providing more reliable data.
- Easier to understand, Less complexity
- Better code reuse
- Less bugs
- More efficient
- Different team members can work in different areas.