11.5 Metrics based on objects

Metrics based on objects

Metrics based on classes and source code can provide most of the information you'll ever need to help you estimate workloads and find problem areas in your design or implementation. Unfortunately, they do not necessarily tell you about the size and performance of your running application. Metrics based on objects can do this. They also can help you determine whether or not classes and objects are reused. You could retrieve the same information straight from the source code, but it would be quite a bit harder.

Number of instances

Counting the number of instances tells you about performance and resource characteristics of your application. At the beginning of this chapter I introduced a simple mechanism that counts instances automatically. Once you have these numbers, you can identify resource-intensive parts of your application as well as performance bottlenecks.

There is no general rule about how many object instances you should have. Obviously, bigger applications have more instantiated objects than smaller ones. However, it is still interesting to see how many objects are instantiated and also how many objects are instantiated at any given point in time.

Number of times a class is reused

Class reuse is key to successful object-oriented projects not only across projects, but also within a single application (see Chapter 8). For this reason, it's important to know whether classes are reused properly. You can analyze source code to see whether they are instantiated or subclassed in many different places, but it's hard to tell whether that code is ever executed. When counting instances as described at the beginning of this chapter, it is easy to determine which classes have been instantiated how often, what their parent classes are, and so forth.

Number of dependencies

When one object depends on another object, the first object gets harder to reuse. For this reason it is important to keep the number of dependencies as low as possible. If you have to have dependencies (and every system will need many), you need to know what they are. A good object model is a good and easy way to document object dependencies. If you have a good model, you don't need to measure dependencies at the implementation level, but if your model lacks some detail, metrics is another way to find and document dependencies. Unfortunately, this is a non-trivial task. Typically, you would scan the source code to find object checks (Vartype(x)="O") or object instantiation within a method.

However, due to the complexity of this task, I recommend working on a good model instead.