Difference between revisions of "The Blob"

From CloudScale
Jump to: navigation, search
(Detection)
(Solution)
Line 38: Line 38:
   
 
===Solution===
 
===Solution===
In vehicular traffic, the one-lane bridge problem can be resolved by constructing multiple lanes, constructing additional bridges, or rerouting traffic. In the realm of software systems we have similar solutions:
+
keep related data and behaviour together. An object should have most of necessary data to
* Increasing the number of threads (or processes) that can simultaneously access the resource. In our example above, this can be achieved for example by using multiple tables that can be consolidated later.
+
make a decision.
* Reducing the holding time, by limiting the time every process needs to hold the resource, either by removing code from the holding-block that does not need a lock on the resource, or reducing the service time of the resource.
+
As in the example of the Controller and the Valve, one possible solution to reduce the messages is to
  +
check the valve status locally inside the Valve class (keep related data and behaviour together).
  +
So the openValve() operation in Controller is changed to:
  +
void openValve() {
  +
theValve->open();
  +
}
  +
and the open() operation in Valve becomes:
  +
void open() {
  +
if (status != open)
  +
status = open;
  +
}
  +
Now it only requires one message to open the valve.
   
 
===See also===
 
===See also===

Revision as of 13:09, 5 November 2013

Contents

The Blob

Also Known As

The god class

Example

assume we have a process controller program. There are Controller and Valve Class as Figure 3.1 shows. This example is from [1].

Context

Systems with concurrency and mostly those that access a database.

Problem

this problem occurs when one class performs most of the system work relegating other classes to minor, supporting roles. As in the example, the Controller does all the system work, openValve and closeValve. The Valve simply reports its status (open or closed) and answers the Controller’s invocation, open and close respectively. The Controller requests information, make decisions and orders the Valve to open or close. For example, if the Controller wants to open the valve, it must get the current status from the valve first and tell the valve to open. See the code below: void openValve() { status currentStatus; currentStatus = theValve->getStatus(); if (currentStatus != open) theValve->open(); } In the case when the valve is closed, it costs two messages to open the valve including one unnecessary message. This could potentially lead to unnecessary message traffic, which hinders scalability.

Detection

unkown

Solution

keep related data and behaviour together. An object should have most of necessary data to make a decision. As in the example of the Controller and the Valve, one possible solution to reduce the messages is to check the valve status locally inside the Valve class (keep related data and behaviour together). So the openValve() operation in Controller is changed to: void openValve() { theValve->open(); } and the open() operation in Valve becomes: void open() { if (status != open) status = open; } Now it only requires one message to open the valve.

See also

Traffic Jam

References

  1. A. Wert, J. Happe, and L. Happe, Supporting Swift Reaction: Automatically Uncovering Performance Problems by Systematic Experiments, in Proceedings or the International Conference on Software Engineering (ICSE), 2013.
  2. C. Smith and L. Williams, Software Performance Antipatterns, in Proceedings of WOSP. ACM, 2000, pp. 127–136.