Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Hi there,
There is an issue with role permissions that is being worked on at the moment.
If you are having trouble with access or permissions on regional forums please post here to get access: https://www.boards.ie/discussion/2058365403/you-do-not-have-permission-for-that#latest

Java Design question (basic)

  • 24-01-2007 3:35pm
    #1
    Posts: 0


    Hi all,

    I've been thinking about this code situation that has come up and I think I may have a solution that makes both sense and reduces the code overhead.

    However, I just would like to ask your opinion on whether or not it's a bit overkill

    I have 3 panels, each extending from JPanel: PanelA, PanelB, PanelC.

    Each of these panels need to access four different methods (to perform the same task) and the methods are the same for each of them. However, each of the four methods rely on one other method that DOES require definition from each of the 3 panels.

    I thought of inheritance, where one AbstractPanel could provide the four methods and have one method abstract and then each of the 3 panels could define that one abstract method. This, to me, makes sense.

    This may seem basic and, as I'm writing it down, it seems trivial. But my question is that if I were to go ahead with inheritance, would that be overkill and be slightly pointless?

    I will never have to refer to the 3 panels by an abstract base class reference (e.g. AbstractPanel p = new DefinedPanel()) and, in code I've seen, seems to be the sole reason for using abstract classes.
    In my head, it just makes sense to group functionality like this and I'm wondering if I'm right in this, is it overkill or is there a better way to design such behaviour?

    Any insight into this type of design would be appreciated. Apart from just coding, i'm trying to better organise code so as to be more "future-proofed". Thanks, sorry if it sounds all over the place


Comments

  • Closed Accounts Posts: 619 ✭✭✭Afuera


    Yes, if I'm reading what you say correctly, I'd agree with what you suggest.

    I think that what you are saying is that you want to extend JPanel with a MyGenericPanel class (which would be abstract). This would contain implementations for your 4 common methods and a single abstract method. The PanelA, PanelB and PanelC classes would extend the MyGenericPanel class and implement their own versions of the abstract method. Is this what you mean?

    If so, I'd say fire ahead with that. It doesn't sound overkill at all. While you may not require the use of polymorphism in your code, it would allow it to be added in easily if required later on. Also, should someone need to create a PanelD at some stage all they need to do is extend your MyGenericPanel. There's also a maintenance advantage in having the 4 common methods in only one spot should a bug or two crop up there.


  • Posts: 0 [Deleted User]


    Yes, that is exactly the situation I'm in.

    Thank you for your advice.
    I feel more confident in my solution after reading that, I just wanted to be sure that I wasn't going completely over the top.

    Thanks for that.


Advertisement