In fact, if you insist on code/data separation and you’re an advocate of OOP, then you’re talking out of both sides of your mouth. If your gut reaction to having log entries know how to transform or process themselves is “woah, that’s just wrong”, think again: you’re imposing a world-view on the problem that’s not consistent with your notions of data encapsulation and active objects.



Think about this, hard, the next time you are considering the virtues of putting everything in a Relational Database. Code/data separation means that the applications of the future can operate on the data of today. Fine.But then you decide that all applications should access the database through stored procedures, encapsulating the data schema. You just reversed yourself, you might as well have built middleware in a real programming language and exposed the data through web servcies or REST.Either approach is fine. But just recognize that separating code and data works towards the goal of reusability in a manner that is diametrically opposed to building an encapsulation layer.