It depends- basically, the approach is to not think of OOP as the default approach, just one of the tools in the box. When you have a algorithm that goes Red-H

It depends- basically, the approach is to not think of OOP as the default approach, just one of the tools in the box. When you have a algorithm that goes Red-Hot, use Data-Orientated-Programming. When you have lots of annonymous objects repeatetly passing through recombined pipelines, with minimal work, try a functional approach. Try to see OOP not as the final stage of a masterpiece, rather as the launch-pad - and a first working version. Also- what is the best approach, highly depends upon the goals of the project. Speed at all cost? Safety trumps all? Rapid development? Scale-ability? PS: Regarding Object-Relational Databases- i found the true nest of snakes to be that for each object basically a small hand crafted version of git is needed to resolve the changes, once several applications start using the same DB. Not only that, but changes made, that relate to the changed data, needs to propagate- and can not do so only by simple trigger, but often by program-logic. Sloppy work can lead to data fragments being part of two separate objects. What if two programs use one of two classes, but one resides within the other? Who has the right of update? In addition ORM can hold duplicates of a Datum, and very soon, the urge will appear to replace every datafragment in your saved object with a pointer (key) to one, and only one instance of the real-world data piece. TL,DR; This is one of the cases, where the pain comes not instantly, but after a while - and then never leaves. Get somebody who witnessed something like that blow up in another company to help you avoiding the worst.