Doer And Knower

DoerAndKnower AntiPattern represents a lack of encapsulation.

This can often first be detected by looking at class names and their contents. Often seen when classes with "verb" names that are full of code that operate on other simple struct-like classes that have the knowledge.

And what is this antipattern? This page fails to define it, so I have no idea what's being discussed. --MarnenLaibowKoser 20 June 2011

I think what is meant is the AntiPattern of not doing OOP. Instead traditional StructuredProgramming is OOP-ified and the data structures are operated on by specialized methods. This can be the right way if the data structure is hidden behind a facade and the data structure is complex (think of a GIS data structure with lots of wing pointers for geometric neighbors). But if the objects are simple data holders to be used by client code this is an AntiPattern. -- GunnarZarncke

Imagine the following: The class OrderProcessor? has no internal state, but an awful lot of methods that accept and give out OrderEntry? objects. On the other hand, the class OrderEntry? contains nothing but member variables, perhaps with some simple getFoo and setFoo methods for each (if you're lucky). The OrderProcessor? class makes no sense without an OrderEntry?, whilst an OrderEntry? makes no sense without an OrderProcessor?. A more OO approach would be an Order class with the same member variables as OrderEntry? and the same methods as OrderProcessor?, thus the implementation of an order is encapsulated in the Order class.

Note: if a there is a real "order processor", for example a server, then it is not an AntiPattern to model this with a class. Such a class would encapsulate the communication to and from the "order processor" though, and would not perform all Order manipulation. Orders should know how to take care of their own state. In the above example, the separation of Order and OrderProcessor? serves no purpose other than to keep state (Knower) separate from code that manipulates that state (Doer). This destroys encapsulation.

In C++, certain classes (namely PODs and now standard layout classes), have extra guarantees about the layout. Using something like this can allow one to get around the restrictions on those classes while still gaining those gaurantees. Most likely, you would have the OrderEntry? class be private or protected.

This smells a little bit like a DataOriented-AntiPattern / InformationOriented-pattern. I just don't have enough experience to be able to tell. -- JonGrover

CategoryArchitectureAntiPattern