1

I'm stuck on this for hours. I should make UML class diagram for Swing application in a college project. I envisioned one main screen from which I can open one of several screens depending on chosen option. All of those screens have several identical components (like application logo, log out button etc).

Now, I've read it's not recommended to inherit JFrame so I avoided putting those in a class that inherits JFrame that is again inherited by those other classes but somehow it also does not seem okay to not have inheritance and instead list those components as attributes in every class.

So, what IS the right way to do it?

K.Z.
  • 13
  • 1
  • 4
  • Where did you learn that inheritance restriction? – qwerty_so Jun 25 '17 at 19:13
  • 1
    Uhm, all over the internet, stack overflow included. Just to name a few https://stackoverflow.com/questions/1143923/why-shouldnt-you-extend-jframe-and-other-components http://thebadprogrammer.com/2012/08/swing-composition-vs-inheritance.html – K.Z. Jun 25 '17 at 19:38
  • What about the last paragraph in this very article? – qwerty_so Jun 25 '17 at 19:44
  • So I should be using inheritance? I read that paragraph and it sounds like what I need, but then I read in lots of other places that composition is always better so I got pretty confused with the whole thing and decided to ask here – K.Z. Jun 25 '17 at 19:52
  • Generally there is no black and white. Follow your instincts. Sometimes it's a question of style, but bad style does not mean it's wrong. Style also evolves over time. – qwerty_so Jun 25 '17 at 20:08
  • Not often I like Killian's posts, but now I totally agree. Model up to logic, up to SOLID principles, but not up to fashion. – Gangnus Jun 26 '17 at 08:52
  • Thank you both for your answers – K.Z. Jun 26 '17 at 17:17

1 Answers1

0

Any different screen are usually considered as a class. The screen with concrete data in it is an instance of the class.

Any sort of subelement of the screen is obviously, another class. Again, its exemplar with date is an instance.

A screen class has subelements of different classes. They really ARE attributes, and changing the natural logic would be very unhappy idea.

If screens have same elements and differ only in their content, and this fact is conceptual, if they MUST be the same, those screens belong to the same class. If they are so similar only accidentally, and further development can change it, they should belong to different classes.

Inheritance could be conveniently used, too. If you have yellow buttons and yellow buttons with dots, the latter could be descendants of the former. Here the Liskov principle won't be broken. Don't forget, the base principles are set in SOLID, there is NOT such principle as don't use inheritance, and you needn't use composition out of pure fashion.

Gangnus
  • 24,044
  • 16
  • 90
  • 149