Instead of saying "don't do X", wouldn't it be easier to show a bunch of examples and let people map it onto their own problem space? Here, I'll start. These

Instead of saying "don't do X", wouldn't it be easier to show a bunch of examples and let people map it onto their own problem space? Here, I'll start. These are some class names in my big depot here. They're not perfect, but what is? Dep: from my build tool, it's a dependency, like when you do #include "foo/bar.h", then foo/bar.o is the dep, and it is built from foo/bar.cc and foo/bar.h. It figures out the inputs and outputs and whether it needs to be rebuilt, and can do the building, too. DepTracker: it tracks all of the Deps. It's responsible for creating them as necessary and making sure they're all built (compiled) and ultimately linked if building a binary. HttpClient: uses libcurl, generates GETs and POSTs and the like, for tasks like fetching feeds (Atom/RSS), talking to Mozilla's Persona (browserid), and Stripe. HttpServer: uses libmicrohttpd, and gives the program an embedded HTTP server. This is great for debugging info. FormatPost: takes my flat text in and gives back formatted HTML for my "/w/" posts, Atom feed, or even the books. MySQLClient, PGSQLClient: interfaces to those external libraries as you would assume. ParseAtom, ParseRSS: turns different flavors of XML into something a little more reasonable for my own purposes. TCPSource, USRPSource, OsmoSDRSource: for different kinds of GNU Radio input scenarios. These are just a few of the larger set. The word "Manager" does not appear in any of them, but that wasn't a conscious decision. It just hasn't happened.