Figure 1.6 shows the system consisting of these six components, not including the test class. At the moment there is no defined relationship between any of them. It is only a decomposition of the various components within the system. In general, when designing an object oriented software system, the thing that you want to do is to determine what the possible components are, and what the responsibility of each will be. In the current example, the entity Name will define names only; the entity Address will be restricted to facilitating address only. As it stands, there is no relationship between a name and an address object. Should there be an error within any of the two, then we would directly focus on the one that has the problem. There would be no need to interfere with the other entity. These two components are now said to be highly cohesive. In terms of customer on the other hand, in real life a customer has a name and an address. Against this background, the entity Customer will have both attributes - Name and Address. That is, both entities must be physically a part of the Customer entity. This consideration therefore establishes an association relationship between the component Customer, and the components Name and Address. This situation is represented by Figure 1.7. With regards to the ease of detecting and correcting errors, if we know for sure that the entities Name and Address are clear of any logic errors, but the component Customer has some form of logic error, then the problem must lie with the current component. Either that it has introduced new variables that are causing the problem; or, the established components are being used improperly.
Figure 1.6 shows the system consisting of these six components, not including the test class. At the moment there is no defined relationship between any of them. It is only a decomposition of the various components within the system. In general, when designing an object oriented software system, the thing that you want to do is to determine what the possible components are, and what the responsibility of each will be. In the current example, the entity Name will define names only; the entity Address will be restricted to facilitating address only. As it stands, there is no relationship between a name and an address object. Should there be an error within any of the two, then we would directly focus on the one that has the problem. There would be no need to interfere with the other entity. These two components are now said to be highly cohesive. In terms of customer on the other hand, in real life a customer has a name and an address. Against this background, the entity Customer will have both attributes - Name and Address. That is, both entities must be physically a part of the Customer entity. This consideration therefore establishes an association relationship between the component Customer, and the components Name and Address. This situation is represented by Figure 1.7. With regards to the ease of detecting and correcting errors, if we know for sure that the entities Name and Address are clear of any logic errors, but the component Customer has some form of logic error, then the problem must lie with the current component. Either that it has introduced new variables that are causing the problem; or, the established components are being used improperly.
chapter1.3.docx