Skip to content

Page385

Coupling and Cohesion

Coupling and cohesion are two concepts used to describe objects. A highly coupled object (such as Addy) requires lots of other objects to perform basic jobs, like math. An object with high cohesion is far more independent: it can perform most functions independently. Objects with high coupling have low cohesion, and the reverse is also true: objects with low coupling have high cohesion.

Addy is highly coupled and has low cohesion: he must delegate any message that does not contain a “+.” Imagine another object called “Calculator,” which can add, subtract, multiply, divide, perform square roots, exponentiation, etc. Calculator would have high cohesion and low coupling.

Learn by Example

Managing Risk Through Objects

Objects are designed to be reused: this lowers development costs. Objects can also lower risk. Much like strong encryption such as AES, the longer an object remains in secure use, the more assurance we have that the object is truly secure. Like encryption algorithms, as time passes, and countless attacks prove unsuccessful, the object demonstrates its real-world strength.

Let us assume your company has been selling information security books online for the past 5 years. Your website allows users to choose a book, such as TCP/IP Illustrated by W. Richard Stevens, and enter their name, address, and credit card billing information. Credit card transactions are risky: risks include disclosure of customer’s PII, as well as risk of credit card fraud; stolen cards used to fraudulently purchase books.

The website is programmed in an object-oriented language. It includes a credit card processing object called CCValidate, first written 5 years ago. The input message is the credit card number and expiration date entered by the customer. The output message is binary: “approved” or “denied.”

The CCValidate object hides the complexity of what is happening in the background after the input message of credit card number and expiration date are entered. It performs the following methods:

  1. The object has variable buffers for the credit card number that perform bounds checking.
  2. The object ensures that the input message is the proper length and contains the proper types of characters in each field.
  3. a. In the case of a MasterCard®, 16 numbers (the credit card number), followed by the date (two-digit month followed by a four-digit year).
  4. b. Any input message that does not meet these criteria is immediately rejected.
  5. The object ensures the expiration date is in the future.
  6. a. Any input message that does not meet this criterion is immediately rejected.
  7. The object then evaluates the format and self-checking digits within the entered credit card number.
  8. a. Valid MasterCard® numbers start with 51–55, and have 16 digits.
  9. b. They must also contain proper self-checking digits. i. See http://web.eecs.umich.edu/~bartlett/credit_card_number.html for more information
  10. c. Any input message that does not meet these criteria is immediately rejected.
  11. The object then sends a message to the proper credit card company server, checking to see if the card is valid and contains enough balance to make a purchase.
  12. a. The credit card company sends a return message of “accept” or “denied,” which the credit card object sends to the Web server as a message.

As CCValidate is used, bugs may be discovered and fixed. Improvements may be identified and coded. Over time, the object matures and simply does its job. It is attacked on the Internet; attackers launch buffer overflow attacks and insert garbage numbers, and the object performs admirably.

If a new site comes online, the programmers should not create a new credit card validating object from scratch: reinventing the wheel is too risky. They should manage their risk by locating and using a mature object that has stood the test of time: CCValidate.