« Wizard task revisited | Main | So that's what's in a name »

AOP and polymorphism again

It looks like my ramblings have been noticed. A post where I was discussing how several AOP patterns could be done in non-AOP frameworks and languages (much like OOP and non-OOP) was responded to in a fashion of "My AOP is not like that! AOP is the second third fourth coming of High Level Language Nirvana!" Ok, it really wasn't that extreme but it was really fun writing and editing the last sentence. However I do feel that some of my comments were misunderstood in the response.

Rickard's response focuses entirely on my composition comments, first starting with my analogy of the Denali and the Geo Metro.

When you think about it though composition is a OOP way to achieve separation of concerns. It was the casting example that made me jump out and say that it can also be accomplished via multiple inheritance. But in that case you lose the possibility of composing the object of sub-classes of the pieces, like a V-8 engine for a Denali v.s. a 3-cylinder for a Geo Metro. At a cursory glance it appears that using AOP to gain this type of composition also suffers from this flaw.
It doesn't, not in my framework anyway. You can either specify a default implementation for an interface, or you can specify that a particular implementation of an interface is to be used in a specific composition. This accomplishes what is outlined above. [ Random Thoughts ]

My analogy wasn't perfect, although it serves some purpose. A better example may be a Saturn VUE. You can get one with a 4 cylinder or V6, and you can get 4WD or AWD. A few sentences after the quote rickard had I mentioned that this can be solved by flattening out the hierarchy, as Saturn does. All four possible compositions have their own class. At this level the combinatorics aren't that bad. Now let's consider that each car can have any of 3 stereo systems, 2 interior colors, 7 exterior colors, and about 5 other options. 2*2*3*2*7*2*2*2*2*2=5376 possible ways to have your saturn. Now what if we added a third type of braking system (Anti-Injury Inertial Dampening Brakes)? One of those 2's become a 3 and we need over 2000 more ways a car can exist, and creating one class per car type is expensive in the hierarchy alone!This is what I meant from flattening the hierarchy. (Full disclosure: we are 2 Saturn family, but don't own a VUE.)

Having not seen Rickard's code, I cannot be sure if he is creating a concrete class for each combination, but there are two possibilities I see from reading his posts. The first is that he is only creating the 10 particular concrete instances he would use out of the huge combination space. Which is fine if you can statically prove that those 10 would fit your needs. The second is that he is storing them and the class is actually a proxy, and the cast to (ACL) is casting to a proxy that forwards all requests to the concrete class. Instead of writing or dynamically generating that big old proxy class why not just write one interface ACLable with one method, getACL()?

Neeext.
What if I want Unix type User-Group-Other ACLs on some and NTFS every-possible-permutation style ACLs on other objects? You could flatten out the classes and make two ACL type. But this false when that choice varies not based on type of object but arbitrarily per object.
I don't think that is very realistic. What is realistic is that a bunch of objects in a system are somehow similar and have the same way of handling the ACL interface. [ [ Random Thoughts ]

It wasn't the realism I was trying to address with this example, which was not about how the files are stored but about the ACL itself. In the next section Rickard describes how he solves this is to flatten the hierarchy into 3 cases, which is what I described as well more or less. I could find a more realistic example but apparently they are not in your system. I was trying to describe a composition that was not binary (ACL v.s. no ACL) but had more complexity, in this case trinary (Unix ACL, NTFS ACL, no ACL). The fact that the example dealt with file systems and storage was what was focused on rather than the implications of the different ACL schemes that they have. Both can validate create, read, update, delete permissions but have wildly different ways of coming to those decisions and different data sets to draw from. But this seems to be more the realm on the Strategy Pattern that the Composition pattern, which is another design pattern that can use and abuse polymorphism and late binding. Objects requiring arbitrarily changeable components may not be the case in your system, but when you really need them you really need them.

Well, I really need to get work done today.

About

This page contains a single entry from the blog posted on October 22, 2002 8:54 AM.

The previous post in this blog was Wizard task revisited.

The next post in this blog is So that's what's in a name.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33