1

This may seem like an odd question, but I'm trying to practice writing reusable code, or least trying to practice thinking about it in the right way, if you know what I mean? I have an assignment that involves writing a text interface with a couple of different menus. So there are two approaches to this: (1) a class for each menu (sloppy) or (2) a class which contains the information for all the menus (not as sloppy).

Now that I am writing this, it feels like it might be bad practice, BUT is it possible to have one class which contains the basic components of a menu (a title, a list of MenuOptions etc), but the methods can be added at another time?

Alternatively, if this is not possible/advisable, which would be the generally preferred way of doing something like this, (a) separate classes for separate menus, or (b) one big class which contains all the code for the different menus?

JoshDM
  • 4,939
  • 7
  • 43
  • 72
user3593486
  • 47
  • 2
  • 7
  • 1
    I don't really fully comprehend what you are saying, but just the `"a class for each menu(sloppy) or a class which contains the information for all the menus(not as sloppy)"` bit, actually, separating in distinct classes is better when possible (as long as it doesn't compromise the meaning). Have a look at the [SRP principle](https://en.wikipedia.org/wiki/Single_responsibility_principle), what I'm saying may make more sense after that. – acdcjunior Aug 20 '15 at 15:05
  • "a class for each menu(sloppy) or a class which contains the information for all the menus(not as sloppy)." If you are trying to practice reusable code, I wonder how reusable the code would be if you have everything in one class? I would say keep things separate into small manageable & testable classes. – Kevvvvyp Aug 20 '15 at 15:12
  • Sadly I have no code(still planning how i will approach this assignment), i know its kind of hard to understand. @acdcjunior Usually I would agree with you, but when it comes to menus, each menu option is responsible for a different thing in the program, or at least responsible for calling different methods in the program. – user3593486 Aug 20 '15 at 15:14
  • It seems that you can use an abstract Menu class, and a different class for each menu that extends it. – uoyilmaz Aug 20 '15 at 15:14
  • "each menu option is responsible for a different thing in the program", this could be yet another reason to separate them into different classes. But, anyway, I'm just speculating, without code, it becomes difficult to assert anything. Just as a general rule, though, you don't want a class changing for more tha one reason (aka having multiple responsibilities). – acdcjunior Aug 20 '15 at 15:18

4 Answers4

1

I think I understand what you mean, but I also think that when you say but the methods can be added at another time? you mean that what the methods do is added at another time.

Menus, in your case, usually need to take care of some basic things, such as

  • Showing the actual menu text (let's call it title);
  • Showing a tool tip;
  • Doing something when clicked.
  • Child sub menu items.

To achieve this, you could use either or a mix of two things:

  1. The strategy design pattern.
  2. Abstract classes.

The strategy design pattern allow you to specify a behaviour, and then pass it along to some class which knows what to do with that behaviour. In short, your behaviour could be what happens when the menu item is clicked. So basically, your menu class will not know what to do when it is clicked, but it will know to whom the call will be delegated. This approach would allow you to have one Menu class and several behaviours it can access.

Using abstract classes is similar to using the design pattern, however, you would end up creating a new concrete class for each different menu you want to have.

Thus, I think that the best result would be somewhere in between.

For instance you could create your Menu parent class as abstract, with properties such as Title, Tooltip, etc. You could then add a method called onActionPerformed which takes in some object which handles what happens when the menu item has been clicked. Lastly, you could create abstract methods such as onBeforeActionPerformed and onAfterActionPerformed, this would essentially be interceptors which would allow you to do logic just before and after the event handling.

You could then extend the Menu class with things such as NonInterceptibleMenu and the likes to handle the different scenarios.

npinti
  • 51,780
  • 5
  • 72
  • 96
  • Thank you, this is exactly what i was asking. Abstract classes seem to be what I am looking for, so I will need to look into that more. Also, thank you for that resource for design patterns. Bookmarked for extensive study. – user3593486 Aug 20 '15 at 15:23
  • @user3593486: If the only different thing that the menu items need to do from each other is what happens when clicked, the design pattern will help (this is what Swing does). – npinti Aug 20 '15 at 15:25
1

You may be confusing having different classes versus having different instances of a class. For example, you could have one class for menus, but two different objects of that class, one for each menu, each with its own set of data describing the menu items and what they do, because each pretty much works the same way, but on different data.

Alternately, if the menus behave differently but have some commonality, you might want to define a class for the common bits, and then make subclasses, each with the details about how what sets that kind of menu apart.

Scott Hunter
  • 48,888
  • 12
  • 60
  • 101
1

You could have a general class for a menu-item and for a menu itself (as a collection of menu-items). These classes would not contain any logic regarding on click behaviour, but they would just cover general parts, like UI, layout, title placeholder - general configurations.

You can have 'methods added later'. This can be achieved either with delegates, or with lambda functions. In Java you might have met similar configuration in Swing, when you have buttons and click listeners (or even menus. You can have a look at the usage of JMenuBar, JMenu, JMenuItem classes and their interface might be interesting for you).

You might come across many examples when 'methods are added' as anonymous classes, this was before lambda functions arrived in Java 8

Samurai Girl
  • 978
  • 2
  • 8
  • 13
0

is it possible to have one class which contains the basic components of a menu(a title, a list of MenuOptions etc), but the methods can be added at another time?

From a basic "coding" standpoint, you can create an abstract class where you declare your central components (make sure they are not declared in private scope), and then write a second class to extend your abstract class, where you declare your methods. Unless you plan to have multiple classes extend your abstract class, there isn't a real need to create this separation.

You haven't provided enough of your overall project scope, so I'll keep my answer to this.

JoshDM
  • 4,939
  • 7
  • 43
  • 72