I usually prefer to follow composition over inheritance rule, until I start stepping in the world of Java GUI.In my experience, for adding custom requirements in a GUI components, for example, add custom function in a JButton, usually create a class extends from JButton like this:public class CustomButton extends JButton{    public void customMethod(){    }}I think it is obviously violating composition over inheritance rule, so I try achieving this by composition instead of inheritance, but the problem occurs: JButton has walls of methods, if I use composition, walls of method mapping is required in my CustomButton class:public class CustomButton{    protected JButton button;    public void customMethod(){    }    public void add(PopupMenu popup){        button.add(popup);    }    public void addActionListener(ActionListener l){        button.addActionListener(l);    }    .    .    .}which may require a horrible list of methods to map to JButton. Also there is one more problem: I don't know how to deal with built-in methods that needs JButton as parameters if my CustomButton is not the subclass of JButton. So my question is, if the original class has too much methods, is it reasonable to use inheritance instead of composition?
Is too much methods a valid reason to break the composition over inheritance rule?
object oriented;inheritance;composition
What composition over inheritance really has to say here is that it would have been nice if JButton has been designed with composition polymorphism so your CutomButton method could have been passed into it.  It wasn't.If the client needs access to everything JButton provides (dubious) you now  have to create a bunch of boilerplate delegation methods if you want to do composition the other way around.  There are automatic refactorings that can do dumb work like that for you but it's still yucky for maintenance. Who wants to look at that? Bleh.So you do inheritance.  What does that hurt?  Well the yo yo problem isn't fun.  You avoid that by not creating multiple levels of inheritance.  Problem with that is now you think ok just one won't hurt.  And so does the next guy.  And the next.You can stop that with a final on the class but that's kinda an F.U. to the next guy.  You could do for the next guy what you wish the JButton guy had done for you.  Let them pass you something that implements a CustomInterface with a customMethod() that you'll call. The fancy name for this is object adapter pattern. Now you're doing both inheritance and composition but at least the madness can come to an end.