We're All Platonists
In an interesting article on TSS (Spring 2.0 vs. the Anemic Domain Model), a lot of software developers fought over what makes a cake a cake. It sounds silly, but it's something OO purists fight a lot about - what belongs in their classes and what does not. Specifically, in this case, the question became, "does persistence logic have any place in the domain object classes?" In other words, should your Cake.class have "save()", "delete()", and "update()" methods?
OO programming makes us all Platonists. We stare at the shadows on the wall and try to decipher the true form of Cakeness. Does a cake bake itself, or does the oven bake the cake? Or does the oven just heat stuff, and the cake batter reacts to heat by forming a cake? The shadow silhouettes on the cave wall are less than clear, but we try our best to make our Cake class mimic the true Platonic ideal of Cake. And so we argue and fight about cakeness.
But Platonic forms are problematic. Where you draw the boundaries around your objects and categories is always an arbitrary decision. But more importantly - does it even make sense to consider anything in our system as representative of a Platonic ideal? As programmers, we usually treat our classes as definitive - the ideal form, if you will. The web page where users edit objects is the cave where the shadows play. Understanding the Java ideal from the web page is impossible - it is a mere shadow of the ideal Java class.
But, we could easily take a more database-centric view and consider the data in the rows and columns to represent the true Cake object. The Java class now becomes the shadow puppet, and the web page a description of the shadow play to a blind man. In all this, there is the unstated assumption that something in our system represents the ideal Cake form.
But consider - at any future date, a new client app could come along with a different implementation of Cake. It could read the same data from the database, but present completely different behavior and a different web page or other GUI to its users - effectively changing completely what it is to be a cake. It would make the data its slave rather than vice-versa. So is the Cake in the database or anywhere in our code? Or is it still in our heads? Maybe there is no ideal Cake form - maybe we programmers can learn something philosophy figured out hundreds of years ago - there are no forms, only our concrete implementations.
The upshot would be that software design decisions and arguments wouldn't be concerned with creating a pure and correct ontology - they would concern themselves with the pragmatics of programming - clarity, performance, flexibility, modularily, etc. If "cake.bake()" and "cake.save()" make sense from the vantage of such practical design concerns, then declaring "cakes don't bake themselves" is meaningless. We should let the wisdom of philosophy inform our programming: there is no ideal cake, there is only what we bake.
And maybe programming can inform our philosophy as well: the shadows on the cave wall aren't "mere" silhouettes of their ideal counterparts. The shadows enhance the static ideals, and the description to the blind man improves with every retelling.
OO programming makes us all Platonists. We stare at the shadows on the wall and try to decipher the true form of Cakeness. Does a cake bake itself, or does the oven bake the cake? Or does the oven just heat stuff, and the cake batter reacts to heat by forming a cake? The shadow silhouettes on the cave wall are less than clear, but we try our best to make our Cake class mimic the true Platonic ideal of Cake. And so we argue and fight about cakeness.
But Platonic forms are problematic. Where you draw the boundaries around your objects and categories is always an arbitrary decision. But more importantly - does it even make sense to consider anything in our system as representative of a Platonic ideal? As programmers, we usually treat our classes as definitive - the ideal form, if you will. The web page where users edit objects is the cave where the shadows play. Understanding the Java ideal from the web page is impossible - it is a mere shadow of the ideal Java class.
But, we could easily take a more database-centric view and consider the data in the rows and columns to represent the true Cake object. The Java class now becomes the shadow puppet, and the web page a description of the shadow play to a blind man. In all this, there is the unstated assumption that something in our system represents the ideal Cake form.
But consider - at any future date, a new client app could come along with a different implementation of Cake. It could read the same data from the database, but present completely different behavior and a different web page or other GUI to its users - effectively changing completely what it is to be a cake. It would make the data its slave rather than vice-versa. So is the Cake in the database or anywhere in our code? Or is it still in our heads? Maybe there is no ideal Cake form - maybe we programmers can learn something philosophy figured out hundreds of years ago - there are no forms, only our concrete implementations.
The upshot would be that software design decisions and arguments wouldn't be concerned with creating a pure and correct ontology - they would concern themselves with the pragmatics of programming - clarity, performance, flexibility, modularily, etc. If "cake.bake()" and "cake.save()" make sense from the vantage of such practical design concerns, then declaring "cakes don't bake themselves" is meaningless. We should let the wisdom of philosophy inform our programming: there is no ideal cake, there is only what we bake.
And maybe programming can inform our philosophy as well: the shadows on the cave wall aren't "mere" silhouettes of their ideal counterparts. The shadows enhance the static ideals, and the description to the blind man improves with every retelling.
posted by Michael Stover at 9:16 AM
2 comments
