![]() |
SearchWiki Heuristics.RecentChanges Edit Page Page Revisions |
| Home Design Patterns Heuristics Software Development Software Process Patterns TheIntroduction LogicalDesign PhysicalDesign PatternFoundations GuidelinesAndMyths ReferenceImplementation DependencyPatterns UsabilityPatterns ExtensibilityPatterns MaintenancePatterns AntiPatterns UtilitiesAndTools AllPatterns | Formerly ComponentGranularity.
Classes are too fine grained to be used as an organizational unit on large software systems. Unit of release is the unit of reuse. If classes are reused together, they should be contained within the same component. Reuse does not mean copying code and pasting it into your application. It means you are reusing a component, and that you do not know how the component is implemented. Cohesion is a measure of quality indicating the degree to which an entity performs its intended purpose. Components exhibiting high degrees of cohesion consist of elements that are focused on performing individual tasks, where each task contributes to the overall purpose of the component. Components with lower degrees of cohesion have elements that perform a mish mash of functionality, resulting in components that lack granularity. When designing components, you should strive to achieve a high degree of cohesion by designing designing components that perform a related set of functions. Creating highly cohesive components offers some significant advantages. For intsance, components are independently deployable. A component independent of any other components can be easily deployed as a reusable unit. Classes, on the other hand, can only be deployed with their containing component and all other contained classes are also deployed. These component granularity heuristics offer guidance when designing component contents and behaviors.
|