# Descriptive Observers
**URL:** https://discourse.kitware.com/t/descriptive-observers/313
**Category:** Tips and Tricks
**Created:** [September 11, 2019, 3:45pm UTC](https://discourse.kitware.com/t/descriptive-observers/313 "2019-09-11T15:45:44Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [September 11, 2019, 3:45pm UTC](https://discourse.kitware.com/t/descriptive-observers/313/1 "2019-09-11T15:45:45Z")
# Descriptions for Observers
As one of its primary entrypoints, SMTK’s Observer pattern enables
consuming projects to dynamically interact with SMTK objects. Because
Observers have the ability to change the functionality of an
application, they are a common site for debugging. We have added API
to Observers to describe an Observer as it is inserted, allowing for
the query of an observer’s function during execution.
### Structure of a description
Observers now accept an optional additional string for briefly
describing their function. Additionally, the ADD\_OBSERVER macro has
been introduced to inject the insertion location as an Observer’s
description.
Currently, Observers in SMTK are described by a terse (or not-so-terse), human-readable description of the observer’s purpose. Since these messages will be commonly sifted when debugging logs, are there any suggestions about a preferred format?
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [September 12, 2019, 11:35am UTC](https://discourse.kitware.com/t/descriptive-observers/313/2 "2019-09-12T11:35:30Z")
> [@tj.corona](#):
>
> … are there any suggestions about a preferred format?
Yes:
- Include the class name at the beginning of the description (make it easy to find the source holding the observer code).
- When many instances of a class will each have a separate observer, include the address of the instance or some other unique number in the description so people can distinguish instances.