Why create nodes in their own method?

Question

I see a lot of javafx code something like this:

 private Button getButton(){
      Button myButton = new Button("A button");
      myButton.setOnAction...
 }
 private HBox toolbar(){
      Button file = new Button("File");
      Button edit = new Button("Edit");
      Button props = new Button("Properties");
      HBox toolbarArea = new Hbox();
      toolbarArea.getChildren().add(file, edit, props);
 }

I'm interested in an explanation of why this is done (which I haven't found).

It's generally good programming practice to break methods or functions down into smaller individual tasks. It makes the code easier to read and maintain. The alternative to this style would be to have one long, monolithic `start(...)` method. — James_D, Oct 12 '14 at 17:09
Can you show in which context `getButton()`is called? I don't really get the question. Anyway, it does not seem to be professional code, since a getter method would not create new objects by convention. Besides that, James_D is right. Maybe this is kind of related to the _FactoryPattern_ — jp-jee, Oct 12 '14 at 17:10
Yes, `createButton()` (or `createAndConfigureButton()`) would be a better name for the first method. However, since the methods are private, it doesn't matter too much. — James_D, Oct 12 '14 at 17:11
The question here is one example (getMenu) http://stackoverflow.com/questions/16949178/javafx-borderpane-stackpane-not-resizing-after-children-changed — LilSweden, Oct 12 '14 at 17:13
So You would make "createElement" methods, and then in start do "createElement1(); createElement2(); ...", or? And it's an organizational thing. — LilSweden, Oct 12 '14 at 17:14
Well, in a real application I would use FXML :). But yes, if I were doing this in Java, I would break it into components. If you refactor the example you linked using one long `start()` method, it would be really difficult to look at the code and see the overall structure. — James_D, Oct 12 '14 at 17:16
@James_D alright, if you want to post that as an answer I'll accept it :) — LilSweden, Oct 12 '14 at 17:27

jewelsea · Accepted Answer · 2014-10-13T20:59:14.813

The small method approach works well for internet demo code

Rather than using small methods to define UI elements, the alternatives are:

A very long method unless the application is completely trivial.
FXML defined UI (usually preferred for non-trivial examples, but verbose and unnecessary for small demonstrations).
Separate enclosing objects and classes (sometimes overkill if only aggregation of existing controls is required).

Small methods decrease dependencies on pre-declared objects and program state. Usually the small methods are self-contained and any inputs to them are in their parameter list - it's easier to read and understand them without needing to understand a lot of contextual information and it is also easier to unit test the methods or apply the methods to a more functional programming style, reuse the methods in lambda calls, etc. The names of the small methods also make them self-documenting, so the code is more readable without adding additional comments.

So, in a lot of small, example JavaFX applications you see on the internet, you will find the approach of small methods to describe UI elements, though such an approach is not always the one you should use when you are building larger applications.

Using small methods for UI component definition is an example of an extract-till-you-drop method of programming. Of course, as you can see in the comments on the linked extraction blog, everything is debatable and opinionated, so use your best judgement, but when in doubt, I'd argue in favor or method extraction, not just in the UI definition code, but in your functional code as well.

A concrete example

Take a look at the discussion of JavaFX programming style in the comments on this blog. This is based on this original clock app sample, which does not use small methods, and an updated clock app sample, which is built around many small methods. Per's Lundholm's comment on the original code was this:

A typical sign of not doing it right is when you write comments. Don’t write comments in your code, write code that reads well without comments! I read you code and I think it is virtually unreadable, with all respect. It is a long method sprinkled with constants that carries little or no meaning. If I am given such a code to change, be it fix a small bug only, I start to extract method ’til I drop. It is the fastest way of understanding code.

I suggest you review both sample code bases and decide which you would prefer to maintain. My guess is that you will decide the version with many small methods would be easier to read and maintain.

Use declarative FXML and CSS for larger applications

Also keep in mind, that for many larger applications, use of FXML and CSS is preferred over java code to define and style the UI elements - this is because a large part of defining a UI is often easier to maintain using a declarative syntax rather than a procedural or functional syntax, and FXML is declarative by it's nature (plus it is fully tooled via SceneBuilder and IDE FXML support). Study the SceneBuilder code base for an example of how to use FXML and CSS to define larger UIs.

Why create nodes in their own method?

1 Answers1