User:Bluehat: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
Metrics for CRC Analysis | ==Metrics for CRC Analysis== | ||
CRC analysis metrics can help evaluate the level of ease in designing and coding with CRC cards. These metrics also contribute to other project planning factors to give overall sense of project development. Three metrics are broadly identified as: maximum depth of inheritance, the number of responsibilities assigned to each class and the number of collaborators for a class. These metrics can be calculated easily and quickly without the need of special tools. | CRC analysis metrics can help evaluate the level of ease in designing and coding with CRC cards. These metrics also contribute to other project planning factors to give overall sense of project development. Three metrics are broadly identified as: maximum depth of inheritance, the number of responsibilities assigned to each class and the number of collaborators for a class. These metrics can be calculated easily and quickly without the need of special tools. | ||
Maximum depth of inheritance | ===Maximum depth of inheritance=== | ||
This metric gives an idea of the class hierarchy. It is a count of how many times subtypes of objects is created. E.g. Car is the parent class for Toyota, BMW, and Mercedes .Each subclass shares the overall functions defined in Car class. For short hierarchies, this is a positive benefit of OO. If number of subclasses become too long, it becomes difficult to trace the flow of functions, resulting in overly complex systems. This makes testing, reviewing and reusing difficult. | |||
Number of collaborators | ===Number of responsibilities=== | ||
This is the count of clearly defined set of duties to each class. One class should not have a huge set of responsibilities covering the whole system. This situation in a CRC card would indicate an imbalance in design. We need to refine the overly complex class into a series of simpler objects. This will make the system easier to understand, implement and reuse. For most commercial transaction oriented systems, values approximately between eight and eighteen are common. The design should be reviewed if this count is more than twelve. | |||
===Number of collaborators=== | |||
This is the count of all the supporting classes to help the main classes. Sometimes beginners confuse between collaborators and subclasses. This will create too many collaborators .A check in this case will help correct the inheritance and encapsulation to reduce collaboration. Typical value for this metric is eight. |
Revision as of 17:50, 6 September 2010
Metrics for CRC Analysis
CRC analysis metrics can help evaluate the level of ease in designing and coding with CRC cards. These metrics also contribute to other project planning factors to give overall sense of project development. Three metrics are broadly identified as: maximum depth of inheritance, the number of responsibilities assigned to each class and the number of collaborators for a class. These metrics can be calculated easily and quickly without the need of special tools.
Maximum depth of inheritance
This metric gives an idea of the class hierarchy. It is a count of how many times subtypes of objects is created. E.g. Car is the parent class for Toyota, BMW, and Mercedes .Each subclass shares the overall functions defined in Car class. For short hierarchies, this is a positive benefit of OO. If number of subclasses become too long, it becomes difficult to trace the flow of functions, resulting in overly complex systems. This makes testing, reviewing and reusing difficult.
Number of responsibilities
This is the count of clearly defined set of duties to each class. One class should not have a huge set of responsibilities covering the whole system. This situation in a CRC card would indicate an imbalance in design. We need to refine the overly complex class into a series of simpler objects. This will make the system easier to understand, implement and reuse. For most commercial transaction oriented systems, values approximately between eight and eighteen are common. The design should be reviewed if this count is more than twelve.
Number of collaborators
This is the count of all the supporting classes to help the main classes. Sometimes beginners confuse between collaborators and subclasses. This will create too many collaborators .A check in this case will help correct the inheritance and encapsulation to reduce collaboration. Typical value for this metric is eight.