Write an article, "What do objects do all day?", talking about the various roles classes play in a program. Some classes are, in no particular order, (a) collections of data, all public except for details of memory management and such:
org.w3c.dom.Document, and I guess
String; (b) handles to software entities that live in the kernel or out of process:
java.sql.Connection; (c) data sources and sinks:
Iterator; (d) event handlers—these don't model anything at all, you just use them to hook into other objects; (e) representations of some random programming language concept that the language doesn't have special syntactic support for, like a logic variable, a closure, or a future; (f) models of real-world "things" in the problem domain.
I'm interested in this because I'm interested in what code means. I think having a clear idea of what you mean gets your job done faster, leads to more readable code and a more flexible design, and reduces bugs.
The few object-oriented textbooks I remember at all focused their abstract discussion of “what objects mean” entirely on (f). It was as though the authors didn't really think about the question. But I suspect (without substantiation) that different techniques—and different programming language features—matter in different cases.
Find out if anyone does studies of questions like these: How many arguments does a method take, on average? (You get different answers if you count method declarations, method calls in source code, method calls at runtime.) What proportion of method calls take any complex arguments (I mean, arguments that can't be represented losslessly as smallish strings)? What proportion of methods simply delegate their job to some other object? What kind of changes do people make to existing code? Are there trends in these numbers over time?