stevedoria.net

Scratching your head doesn't make it work any better. It only loosens unsightly dandruff.

Increasing Module Cohesion

When thinking about software modules as service providers and consumers, from time to time, a situation occurs where a service provider and a consumer communicate through a common or shared buffer. In the sockets API, the consumer of a service provides the buffers from which write() sends and to which recv() receives. This can be made to seem sensible, since these I/O functions can be seen as operating on arbitrary buffers. In this case, the buffers can be viewed as owned by or being more associated to the service consumers.

There are other situations where certain buffers are used only when communicating with specific service providers. When many such service providers with their associated buffers are present in a system, it is very possible that the buffers will be placed within a “buffers module,” or a module that consists entirely of buffers. This effectively disassociates the buffers from their respective service providers. Identifying the correct buffer that is dedicated to methods of a service providing module is more difficult, if that buffer is defined as part of another module as opposed to being defined within the module that is providing the service.

An increased risk of duplicate code is realized when buffers are placed in modules other than that of the consumers and providers. Implementers of service consumers may feel the need to independently implement functions to operate on these buffers. The duplication of code may be due to the lack of communication and coordination between the implementers, but this confusion could be minimized by recognizing the logical cohesion between the buffer and service provider, and placing the buffer within the module that outputs its results through said buffer. The service provider is also expected to implement functions that operate on its buffer. This localizes the functions that operate on the buffer to the service providing module, thereby reducing the risk of duplicate code among consumer modules with regard to the buffer and increasing cohesion between the buffer and the service providing module.

Questions, comments, and responses are welcomed. Spam is really not.

Leave a Reply