• Object-Oriented Design

Each module shall be understandable on its own – without knowing anything about other modules.

PSU means that:

• By looking at the public methods of a class it should be clear why they are there. That means there should be no method that is only there because a specific other module needs it.
• By looking at the implementation of a module it should be clear how it works and why it was done that way. That means there should be no code that is solely there in order to make another module work.
• By looking at a private method it should be clear what it does. That means there should be no (private) method that is only meaningful in the context of another method.

When a module is separately understandable, it is easier to maintain, as no other modules have to be considered during maintenance. It is furthermore more testable, as a unit test can easily test only this particular module without requiring integration with other modules.

Another point of view is that a violation of PSU either means that a part of the functionality does not belong to that module or the module has the wrong abstraction. So this is a sign of a design that needs improvement.

When a module does not comply with PSU, this means that either a part of the functionality of the module does not belong here or the module has the wrong abstraction. So strategies for making a solution more compliant with PSU are:

• Move the conflicting functionality to another module where it fits better (see IE).
• Build up a new module for the conflicting functionality (see HC).
• Find the right abstraction for the module that allows the functionality to stay here (see MP).

This principle is newly proposed in this wiki. Nevertheless it is believed that it is not “new” in the sense that its a new insight. Its rather something that is commonly known but hasn't been expressed as a principle, yet.

• Proposed

• Keep It Simple Stupid (KISS): Not to adhere to PSU is sometimes easier.

• Information Hiding/Encapsulation (IH/E): PSU is about constructing a module such that its inner workings (and its usage also) can be understood without knowledge about other modules. IH/E on the other hand is about constructing a module in a way that hides the inner workings so it can be used without knowing them.
• Low Coupling (LC): One kind of couplings are logical couplings. These are especially hard to detect but should be avoided. PSU describes one aspect of these logical couplings, whereas LC relates this kind of coupling to others.
• Model Principle (MP): The model contains the only information that should be necessary to understand the module.

Incomplete