Dont Ask Dont Tell

An AntiPattern in which a single class encapsulates all of the logic for some functionality, and uses its collaborator classes as mere structs to hold data. The "Don't Tell" part refers to the failure to delegate any logic to its collaborators. The "Don't Ask" part describes the property of not even using predicate methods on its collaborators, preferring instead to read the collaborator's attributes and test their values directly.

Class names ending in "...Manager" are a CodeSmell potentially indicating this AntiPattern.

Objection. "Manager" is a completely valid term describing a component responsible for maintaining the operations of some subsystem. This is a model I use all the time in EmbeddedSystems, where certain hardware functionality needs to be aware of its own state and condition changes. Having objects that track state and exhibit behavior isn't enough to glue together a system -- you need decision making as well. The rules surrounding those decisions are embodied in a management component that uses the services offered by its subordinate objects to achieve the goals of the subsystem. "...Manager" is a useful paradigm for encompassing those rules and the decisions involved.


I had to use this AntiPattern yesterday to compensate for the lack of multiple inheritance in CeeSharpLanguage. It seemed preferable to copying and pasting code...


See: FeatureEnvy

Contrast: TellDontAsk


EditText of this page (last edited November 26, 2014) or FindPage with title or text search