Fanciful Magic

The Final Debate Rages!

The latest entry:
>From: "kups28"
>Certainly if you're seeing code or hearing people say
>they're using final because they're code is perfect,
>that's the wrong reason.

I wasn't claiming it to be a reason, but an implication. I think by using final, you're implying that your code is perfect. I think I would look at anyone funny who came right out and said their code was perfect...=)

>Anti-object think? Subclasses should have access to all methods
>in its suprclasses? I couldn't disagree more. One should always
>have the option to have private methods to manage the private
>details of an object. That's part of encapsulation, supports the
>open-closed principle and so on... Many times I've used private
>methods to do work with instance variables that you clearly want
>to be private.

I tend to think of encapsulation from a different point of view. I look at encapsulation from outside of the object. I view a subclass of another object to be from the inside. Now, since I think a subclass is inside the object, then yes, I do believe it should have access to all of the methods of the super class, but not its instance variables. The reason I don't believe in giving direct access to instance variables of the super class is because it's too easy to change the super class. With methods, you can deprecate them if need be.

I think we just have different opinions on where subclasses lie in regards to encapsulation. I see subclasses as having the inside track and you're opposed to that. I think that's too conservative and you probably think my definition is too liberal. I think if someone is subclassing your class, they should have all of the inside knowledge they need. My point is that you never know how someone might extend your class and they might want to do something before/after a private method that you have implemented. Now, the developer could 1) either beg you to make it not private or 2) copy the private method verbatum and then make their changes.

The anti-object thinki comment might have been a little bit overboard....=)

>One example that comes to mind is an object that has an internal
>hashtable that it needs to manage. Perhaps for performance, it
>needs to change the number of buckets in the hashtable once it grows
>to a certain size. If the class doesn't/shouldn't/etc. expose the
>hashtable to its subclasses, I sure as heck wouldn't want to make a
>the hashtable management method protected.

Alright, in this example, I would refer to the "hashtable" by an interface and if I needed to change implementations of the hashtable for performance I could. I would simply change the object that is internal to my class. I tend to use interfaces in my instance variable declarations where *I think* there might be issues like this one. That way my object that uses the hashtable calls the interface and the implementation of the hashtable can change. I usually provide a method to initialize the instance variable so subclasses could change the implementation if they like. I would make all of the hashtable management in the hashtable implementation and my containing class would simply switch out implementations (the logical for when to switch would not be in the containing class at all, I would ask the implementation if it was getting to big and if so, would the next implementation be). This makes the hashtable a strategy pattern that knows what its next strategy is possibly.

>That may not be a typical example. Perhaps a better one would be
>an object that manages i/o details to from a database, file, etc.
>I can think of compelling reasons never to expose some of those
>details.

Again, I would have an object that exposes what I needed from the file, database, etc and then simply have implementations that went to the database or file. The containing class wouldn't care. Now, would I subclass those implementations? No.

I guess the bottom line is that I don't like to limit people when they are using my code. I never want someone to go "if I could only change this one aspect of my superclass". People can be very inventive and copy/paste gets around a lot. Then, we have code duplication complicating matters. Don't laugh, at my work, this is how someone got around a lot of private code that another developer had written. I kid you not.

I just think we have different experiences. I've had several bad experiences with both private and final. It sounds like you have the opposite experience. I think it's hard to come to a conclusion or have a clear winner. I think it's whatever works for the both of us.

>Your comment about never knowing what people will do with your
>class is a valid point. But I still think there's room for
>having well thought out private, protected, and public methods
>(Java terms here, but I'm really thinking of whatever the
>equivalents are in other languages).
>

I think everyone tries to have their designs well-thought out. I just think circumstances change and code needs to be as flexible as possible. I just think adding private/final makes things too rigid.