 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2006what are the other ways to prevent a class from being subclassed. one way is to declare the class final.
Hi All, what are the other ways to prevent a class from being subclassed. one way is to declare the class final. Thanks Srinivas You could throw an exception in the ctor, if it's being called on a derived class: class NoExtend { public NoExtend() { if (this.getClass() != NoExtend.class) { throw new RuntimeException(); } } } Or you could have a private ctor, with a public factory method: class NoExtend { private NoExtend() { } public static NoExtend create() { return new NoExtend(); } } Those are two methods that come to mind... Walter ---- Walter Gildersleeve Freiburg, Germany ______________________________________________________ http://linkfrog.net URL Shortening Free and easy, small and green. hi... Thanking you very much for ur help.. Thanks.. Srinivas > You could throw an exception in the ctor, if it's being called on a > derived class: [quoted text clipped - 30 lines] > URL Shortening > Free and easy, small and green. >what are the other ways to prevent a class from being subclassed. one >way is to declare the class final. Why do you want to know another method? What is the matter with declaring a class final?  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Hi All, > > what are the other ways to prevent a class from being subclassed. one > way is to declare the class final. Declare its constructors as private. On Wed, 08 Feb 2006 23:41:01 GMT, EJP <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted someone who said : >> what are the other ways to prevent a class from being subclassed. one >> way is to declare the class final. > >Declare its constructors as private. Doing that and not declaring the class final is what I call "tantalising" . SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. On Thu, 09 Feb 2006 00:06:31 GMT, Roedy Green <my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or indirectly quoted someone who said : >On Wed, 08 Feb 2006 23:41:01 GMT, EJP ><esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted [quoted text clipped - 8 lines] >"tantalising" >. see http://mindprod.com/jgloss/tantalising.html SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > On Thu, 09 Feb 2006 00:06:31 GMT, Roedy Green > <my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or [quoted text clipped - 13 lines] >>. > see http://mindprod.com/jgloss/tantalising.html hehehe. Silly rabbit, tricks are for kids. -- LTP :) > On Wed, 08 Feb 2006 23:41:01 GMT, EJP > <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted [quoted text clipped - 7 lines] > Doing that and not declaring the class final is what I call > "tantalising" Not as tantalising as all that. You certainly don't have to wait until 'bebug time' to discover it as your glossary claims. The first compilation will tell you. More generally you might declare the ctors as package-private: would you describe that as 'tantalising'? inside a sealed package? where you do draw the line? On Thu, 09 Feb 2006 05:51:59 GMT, EJP <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted someone who said : >Not as tantalising as all that. You certainly don't have to wait until >'bebug time' to discover it as your glossary claims. If it is an alternate implementation, you won't find out till run time, or maybe never. The compile will be quite happy so long as your method signatures you use match. If it a totally unrelated class you will find out at compile time, and you will likely be puzzled all the heck why it does not recognise your methods. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > If it is an alternate implementation, you won't find out till run > time, or maybe never. The compile will be quite happy so long as your > method signatures you use match. You will definitely find out, because of super() being private, but actually we seem to be getting a fair way off the point here. A replacement class newly marked as 'final' will also have some 'tantalizing' behaviour at runtime. > If it a totally unrelated class you will find out at compile time, and > you will likely be puzzled all the heck why it does not recognise your > methods. My compiler complains about not being able to call super() because it is private. This doesn't puzzle me. I don't know what is meant by 'not recognizing your methods'. I was really only answering the OP's question for completeness, not to advocate any particular style, but the use of this pattern e.g. for factory or singleton classes seems perfectly legitimate to me, and not 'tantalising'. On Thu, 09 Feb 2006 08:36:19 GMT, EJP <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted someone who said : >You will definitely find out, because of super() being private, but >actually we seem to be getting a fair way off the point here. A >replacement class newly marked as 'final' will also have some >'tantalizing' behaviour at runtime. I am confused since we have been discussing vaguely related issues in different threads. 1. if you use wildcard imports you can get he wrong class and not notice even at run time. All that has to happen is the signatures to match of the methods you actually use. 2. if someone makes all constructors private but leaves the class itself public, someone researching his problem will note the class is not final and base a design on that. when he actually comes to do the work of extending the class he finds out when he compiles he is in trouble since the super constructor is private. He has wasted time designing and writing his class. That is tantalising. Shoot the a.shole who pulled this childish stunt. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. The problems you mention are pretty far-fetched, and would be caught early in production, in any case. Indeed, you'd have to give me an example to show that problem 1) could happen without compile-time errors--normally you'd get a ambiguity error: import java.util.*; import javax.swing.*; class MyTimer extends Timer {//won't compile } As has been mentioned, non-final, non-inheritable classes are useful in certain design patterns, including singletons, abstract factories and prototypes. ---- Walter Gildersleeve Freiburg, Germany ______________________________________________________ http://linkfrog.net URL Shortening Free and easy, small and green. > On Thu, 09 Feb 2006 08:36:19 GMT, EJP > ... [quoted text clipped - 8 lines] > > ... When the constructor is declared private, it can be documented. The developer who does the research will definitely come across the documentation of the class and realize that it has a private constructor and thought it is non-final, it cannot be extended. So it is is common sense that he wud not waste his time developing a subclass to a class which he knows is not inheritable. Besides, nothing stops bad design. The language to its best possible extent prevents accidental design flaws, but intentional efforts cannot be stopped. So if developer decides to create a bad design, it's his call. In object oriented world, contracts rely on other contracts to do what they are supposed to do. There has to be a default level of trust among objects. In an ideal world, developers make their best effort to ensure that their object implementation does what the object's public contract declares to do in the manner that it does. But there is nothing to enforce this kind of nature in the language. > On Thu, 09 Feb 2006 08:36:19 GMT, EJP > I am confused since we have been discussing vaguely related issues in > different threads. Not me. > 1. if you use wildcard imports you can get he wrong class and not > notice even at run time. All that has to happen is the signatures to > match of the methods you actually use. I agree, but this applies to *any* class, whether a mis-import or an alternate implementation, which doesn't entirely meet the binary contract of the expected class. > 2. if someone makes all constructors private but leaves the class > itself public, someone researching his problem will note the class is [quoted text clipped - 3 lines] > designing and writing his class. That is tantalising. Shoot the > a.shole who pulled this childish stunt. I disagree. He has wasted his time by not doing his homework. This applies to many situations, not just this one. In *the situation under discussion*, there may be legitimate reasons for making it non-final but with private constructors. The abstract factory pattern is an example: the concrete subclass can be provided as a static inner class. This seems like a useful feature to me and I may even have used it some time. Your language is not justified. On Sun, 12 Feb 2006 04:38:22 GMT, EJP <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted someone who said : >I agree, but this applies to *any* class, whether a mis-import or an >alternate implementation, which doesn't entirely meet the binary >contract of the expected class. but it won't likely happen because if the class names differ because you explicitly mention the class name in your code. The confusion comes with generic wildcards that can give you an alternative class you did not even know about. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. On Sun, 12 Feb 2006 04:38:22 GMT, EJP <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted someone who said : >I disagree. He has wasted his time by not doing his homework. This >applies to many situations, not just this one. It is a trap for the unwary. There is no benefit in it. It is motivated by malicious pranksterism. So I put the blame on the person who set the trap, not the one who fell into in. Maintainable code should not have traps. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > It is a trap for the unwary. There is no benefit in it. It is > motivated by malicious pranksterism. 1. It is a trap for the unwary. I agree. There are many of these in Java and elsewhere. 2. The benefit has already been cited, but, to re-iterate, it provides finer-grained control over *who* may subclass the class. Consider this form of the abstract factory pattern: public abstract class AbstractFactory { private AbstractFactory() {} public abstract MyObject createMyObject(); public static createFactory() { return new ConcreteFactory(); } static class ConcreteFactory extends AbstractFactory { public Object createMyObject() { return new MyObject(); } } } You might describe the ability to write that as a marginal or dubious benefit, but it is certainly not 'no benefit'. Consider also the case where the constructors in question are protected or package-private. 3. You can ignore evidence all you want, but when you are reduced to speculating on motives (whose?) you are getting pretty ridiculous. On Mon, 13 Feb 2006 02:25:38 GMT, EJP <esmond.not.pitt@not.bigpond.com> wrote, quoted or indirectly quoted someone who said : >2. The benefit has already been cited, but, to re-iterate, it provides >finer-grained control over *who* may subclass the class. Consider this [quoted text clipped - 11 lines] > } >} I don't understand your benefit. With this convolution what the net result Who do you include/exclude doing it both ways. Even if that were true it is too weird and convoluted. Don't do it. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > I don't understand your benefit. With this convolution what the net > result Who do you include/exclude doing it both ways. > > Even if that were true it is too weird and convoluted. Don't do it. It is exactly as 'wierd and convoluted' as the 'private', 'protected', 'public', and default access control modifiers. People who have that access can subclass, others can't. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.