John Ousterhout (the inventor of Tcl/Tk among other things) has this interesting list of software design advice, from which I'll quote the first one:

Design classes around information, not algorithms or time order. Each class should encapsulate and own particular design decisions or information, so that code outside the class does not need to be aware of them. The biggest mistake that people make is to design classes around time: collect all the things that happen at one point in time into a single class.

The principle of using classes to hide information seems clear and resonates with my experience. On the other hand, I'm not exactly sure what Ousterhout means by mistakenly "designing classes around time". If you have a clear understanding of this, can you perhaps share an instructive example of a badly designed class that just "collects things that happen at one point in time" vs a well-designed class that protects its users from complexity by hiding information or decisions? I'm just not sure what the former looks like and whether it really contrasts with the latter.

closed as too broad by gnat, Doc Brown, amon, Greg Burghardt, Ben Cottrell Nov 2 '18 at 19:05

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

Browse other questions tagged or ask your own question.