Quotes About Modularity

It is too early to say whether modules will achieve widespread use outside of the JDK itself. In the meantime, it seems best to avoid them unless you have a compelling need.

If one limits to developing only the kitchen and bathroom as standardized rooms because of their installation, and then also decides to arrange the remaining living area with movable walls, I believe that any justified living requirements can be met.

Certainly not every good program is object-oriented, and not every object-oriented program is good.

I think that that's something that's pretty interesting about a GoPro - it's the one camera that we know of that you can combine with like cameras to form new cameras. So it's a bit of a modular system.

All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.

Are the individual functions in your modules too large? This is not so much a matter of line count as it is of internal complexity. If you can't informally describe a function's contract with its callers in one line, the function is probably too large.9 9 Many years ago, I learned from Kernighan & Plauger's The Elements of Programming Style a useful rule. Write that one-line comment immediately after the prototype of your function. For every function, without exception.

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

In fact, wrapping third-party APIs is a best practice. When you wrap a third-party API, you minimize your dependencies upon it:

Duplication is the primary enemy of a well-designed system.

In general, it is harmful to depend on modules that contain more than you need. This is obviously true for source code dependencies that can force unnecessary recompilation and redeployment—but it is also true at a much higher, architectural level.

We do not want to expose the details of our data. Rather we want to express our data in abstract terms. This is not merely accomplished by using interfaces and/or getters and setters. Serious thought needs to be put into the best way to represent the data that an object contains. The worst option is to blithely add getters and setters.

This means that the UI and the database can be plugins to the business rules. It means that the source code of the business rules never mentions the UI or the database.

When classes lose cohesion, split them!

The architecture of a system is defined by a set of software components and the boundaries that separate them.

If we are diligent about building well-formed and robust systems, we should never let little, convenient idioms lead to modularity breakdown. The startup process of object construction and wiring is no exception.

If a component contains software that should be reused, it should not also contain software that is not designed for reuse. Either all the classes in a component are reusable, or none of them are.

CRP says that classes that are not tightly bound to each other with class relationships should not be in the same component.

Regardless of how they are eventually deployed, well-designed components always retain the ability to be independently deployable and, therefore, independently developable.

ISP: The Interface Segregation Principle This principle advises software designers to avoid depending on things that they don't use.

The topmost parts of the source file should provide the high-level concepts and algorithms. Detail should increase as we move downward, until at the end we find the lowest level functions and details in the source file.

dynamically linked files, which can be plugged together at runtime, are the software components of our architectures.

Classes and modules that are grouped together into a component should be releasable together. The fact that they share the same version number and the same release tracking, and are included under the same release documentation, should make sense both to the author and to the users.

The source code of higher-level services must not contain any specific physical knowledge (e.g., a URI) of any lower-level service.