design - Why create nodes in their own method? -

design - Why create nodes in their own method? -

i see lot of javafx code 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 explanation of why done (which haven't found).

the little method approach works net demo code

rather using little methods define ui elements, alternatives are:

a long method unless application trivial. fxml defined ui (usually preferred non-trivial examples, verbose , unnecessary little demonstrations). separate enclosing objects , classes (sometimes overkill if aggregation of existing controls required).

small methods decrease dependencies on pre-declared objects , programme state. little methods self-contained , inputs them in parameter list - it's easier read , understand them without needing understand lot of contextual info , easier unit test methods or apply methods more functional programming style, reuse methods in lambda calls, etc. names of little methods create them self-documenting, code more readable without adding additional comments.

so, in lot of small, illustration javafx applications see on internet, find approach of little methods describe ui elements, though such approach not 1 should utilize when building larger applications.

using little methods ui component definition illustration of extract-till-you-drop method of programming. of course, can see in comments on linked extraction blog, debatable , opinionated, utilize best judgement, when in doubt, i'd argue in favor or method extraction, not in ui definition code, in functional code well.

a concrete example

take @ discussion of javafx programming style in comments on blog. based on original clock app sample, not utilize little methods, , updated clock app sample, built around many little methods. per's lundholm's comment on original code this:

a typical sign of not doing right when write comments. don’t write comments in code, write code reads without comments! read code , think virtually unreadable, respect. long method sprinkled constants carries little or no meaning. if given such code change, prepare little bug only, start extract method ’til drop. fastest way of understanding code.

i suggest review both sample code bases , decide prefer maintain. guess decide version many little methods easier read , maintain.

use declarative fxml , css larger applications

also maintain in mind, many larger applications, utilize of fxml , css preferred on java code define , style ui elements - because big part of defining ui easier maintain using declarative syntax rather procedural or functional syntax, , fxml declarative it's nature (plus tooled via scenebuilder , ide fxml support). study scenebuilder code base illustration of how utilize fxml , css define larger uis.

design methods javafx nodes elements