What reasoning, or probably concrete criteria, is behind a definition of what parts an object consists of? Does it depend on desired object behavior? Is there a kind of "carving Object at its joints" thing?
I've already read some posts on mereology, but they are quite heavy for me to digest. It seems that an answer is somewhere there though.
Talking about a purpose I pursuit, I'd like to find some philosophical ideas which correlate with an OOP concept called composition. I have my way of composing objects though, which is providing an object with all necessary resources in order for it to be able to do its job which is reflected in a class method. For example, when I model a database table row, I realize that is can't exist without a connection to a database and a query that results in exactly this row. So I put them in a TableRow
constructor. The point here is that domain modeling goes first. So I start with "carving nature at its joints", identifying abstractions, then turn them into a programming concept called interface. Then I want to identify concrete things, which are classes. When I'm done with it, I have to decide what a concrete class should be composed of, since very rarely it does all the job by itself. Once again, all this endeavor lies in a problem space context. It has nothing to do with programming itself. So I thought metaphysics has some answers. Mereology could be a more concrete area, but at the moment I haven't found anything of any particular use.