Posted to the list which was supposed to receive this mail, for some unknown reasons, I jjust replied to Alex instead of posting the ML. Was absolutly not my initial intention...
On 7/18/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
I agree that the Visitor pattern may be overkill in this specific case. Let's just go ahead and keep/add these functions u mention to the BranchNode class. Oh and I do agree that some people are DP morons. I like to think of myself as being a moderate. If useful then use it. But to me the pattern must match the need exactly. I'm not going to bother with using a DP if I have to bend and twist to force the fit. If you're forcing the fit then something is wrong and you're adding more meaning to what you have done than the pattern can express on first glance. And this destroys the primary benefit of the pattern which is to impart an immediate understanding to the code reader/maintainer at first glance. This is the main benefit of patterns in the first place. I feel we live in an age where we have two extremes. Those who overuse patterns and those how completely avoid them. I just want to be moderate about it. No need to make it a religion or to cast it out completely. Hey btw there's a lot of good technical convo matterial here perhaps we should post some of this to the dev list. I did not do it because I thought you just emailed me because there was something sensitive in it. Alex On 7/18/07, Emmanuel Lecharny <[EMAIL PROTECTED] > wrote: > Hi Alex, > > I was looking at the Visitor pattern, and the more I look at it, the > less I think it is suitable for our need in this special case. > > What we have here is a very static tree, with branches and leaves. All > the leaves are the same (Partitions), and branches are just breanches. > > The operations we will use are : > - lookup > - add > - delete > > (the last one has not been written yet) > > If we have to map those operations to Visitors, then we will have to > implement three visitors, when we could have simply declared those > three methods to the main class (PartitionStructure). What I mean is > that this tree isn't handling different kind of objects, so we don't > need to use a complex pattern for such a simple intern fonctionality. > > I would also add that we should not use patterns for everything : it > seems to me that many people are considering patterns as a substitute > to common sense, and are abusing them. I have had this feeling 2 years > ago on a big project when I had a discussion with someone who thought > that Design Patterns were the Alpha and Omega of programming. He was > young (around 27) and was using patterns for everything in his > program. Of course, his project (one out of the 300 projects we were > trying to aggregate) was one of the most cripled and fucked up of all > the projects : nobody was able to handle it because of the overuse of > patterns... But they were no way to tell him to use patterns when > needed only : the GoF book was like a Bible to him, and I was seen as > an apostate to him, deserving to be burnt slowly... > > To be clear : Visitor pattern is ok for Normalization, this is almost > the perfect exemple of good use. We couls also use it for Search. But > I don't think it's suitable for the Partition tree. > > Any other opinion ? > > On 7/14/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > > Also Emmanuel I'd like to see if we can break out the search (lookup) > > functionality > > into a visitor for the tree. As an example you can look at the way this is > > done with > > the filter AST in o.a.d.shared.ldap.filter . Here a visitor can be > > responsible for adding > > new nodes and removing new nodes instead of adding the code to do this into > > the > > node classes themselves. > > > > WDYT? > > > > Alex > > > > > > On 7/13/07, Alex Karasulu < [EMAIL PROTECTED]> wrote: > > > Hi Emmanuel, > > > > > > The code is solid as a rock. > > > > > > I just worked the clarity of it a bit. Essentially you're building a tree > > that is > > > being used as a rapid lookup structure to find partitions corresponding to > > the > > > DN of the entries are contained by a partition. I simply renamed a few > > things > > > in commit 556176 to make it clear as to what you're doing or at least what > > I > > > think you are doing. Notice how much more clear it is when I just renamed > > > the following classes and moved them into an inner package called > > > o.a.d.s.c.partition.tree: > > > > > > PartitionContainer => BranchNode class > > > PartitionStructure => Node interface > > > AbstractPartitionStructure => AbstractNode > > > PartitionHandler => LeafNode > > > > > > I hope this was the correct interpretation of what you meant by these > > names. > > > Please correct me if I am wrong. > > > > > > There still are some things that confuse me like how the lookups are done. > > Could > > > you add some documentation to describe it? Also it seems you are > > sometimes using > > > the partition suffix to check for matching and sometimes using the rdn. > > Could you > > > clarify when one is used over the other? Perhaps breaking up complex > > statements > > > which you join together like this below will make it easier to understand: > > > > > > return current.addNode( dn.getRdn( index ).toString(), > > > buildNode( new BranchNode(), dn, index + 1, partition ) ); > > > > > > Also btw how the index parameter is being used in this recursion is a bit > > confusing > > > could you clarify? > > > > > > I think this data structure might be better integrated directly into the > > Partition and > > > PartitionNexus interfaces. Right now you use it as an alternative data > > structure in the > > > nexus. Perhaps we could make nexus into a branch node and have it contain > > other > > > nexus objects? Meaning a nexus should be what here is modeled as a > > BranchNode. > > > A non-nexus Partition can be the equivalent of a LeafNode. This way the > > data structure > > > is directly integrated into the architecture rather than having it used in > > as an alternative > > > data structure just in the nexus. This way we can gain nested nexus' and > > use the structure > > > in an integrated fashion. > > > > > > Furthermore I know you dislike "patterns" but please try to use the > > correct terminology > > > when you are designing them. I know you old timers just do patterns > > without getting > > > into the jargon of it all but it helps communicate what you are doing > > better to us newbies. > > > People understand tree structures and the language associated with them > > verses things > > > like PartitionContainer and PartitionHandler. If this continues I'm going > > to be totally lost. > > > > > > Thanks, > > > Alex > > > > > > > > > On 7/13/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > > > > > > > You have my +1 for that ! > > > > > > > > On 7/13/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > > > > > I'm looking through this code and it's painful especially with the > > names > > > > > chosen for the interface, > > > > > and the implementations. I'm going to start reworking it a bit so it > > can be > > > > > better understood at > > > > > first glance. > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > -- > > > > Regards, > > > > Cordialement, > > > > Emmanuel Lécharny > > > > www.iktek.com > > > > > > > > > > > > > > > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
-- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
