The thing is that there ought to be no trivial examples of object oriented paradigms because they are never trivial. If you're good you can create object orien

The thing is that there ought to be no trivial examples of object oriented paradigms because they are never trivial. If you're good you can create object oriented interrelations that work but end up having object charts which have that plastic, phoney kind of artificiality that makes little natural sense. If you're a god-like programmer you can come up with interrelations of code and data that make perfect sense but they're quite not always object oriented. As for OO, the best thing I've settled with is this: - Scoop up all your programming experience and first think how do you want to reuse some code or some data structures - Then you go and look up appropriate paradigms and language features that could support your case of reuse - And finally you go figure out how to best do it in a natural way in your programming language. However, I often start with basic lists and dicts and only after something becomes truly obvious and a near-universal trait, I might make a class out of it if I can better reuse code that way. An archetypical example would be something like a BaseObject that supports some protocol for init, deinit, and refcounting, for example. Everything else can adhere to that protocol. Better yet, I'll make it an interface so I can decouple the implementation of the protocol from the definition of the protocol.