Method JavaFx TreeItem getRoot() is not visible. What is the OOP/MVC reason it is not?

Question

I needed to get the root item of a TreeView. The obvious way to get it is to use the getRoot() on the TreeView. Which I use.

I like to experiment, and was wondering if I can get same root, buy climbing up the tree from a leaf item (a TreeItem), using recursively getParent() until the result is NULL.

It is working as well, and, in my custom TreeItem, I added a public method 'getRoot()' to play around with it. Thus finding out this method does already exist in parent TreeItem, but is not exposed.

My question : Why would it not be exposed ? Is is a bad practice regarding OOP / MVC architecture ?

Answer 1

The reason for the design is summed up by kleopatra's comment:

Why would it not be exposed I would pose it the other way round: why should it? It's convenience api at best, easy to implement by clients, not really needed - adding such to a framework/toolkit tends to exploding api/implementation to maintain.

JavaFX is filled with decisions like this on purpose. A lot of the reasoning is based on experience (good and bad) from AWT/Spring. Just some examples:

• For specifying execution on the UI thread, there is a runLater API, but no invokeAndWait API like Swing, even though it would be easy for the framework to provide such an API and it has been requested.

  • Providing an invokeAndWait API means that naive (and experienced :-) developers could use it incorrectly to accidentally deadlock threads.

• Lots of classes are final and not extensible.

  • Sometimes developers want to extend classes, but can't because they are final. This means that they can't over-ride a lot of the built-in tested functionality of the framework and accidentally break it that way. Instead they can usually use aggregation over inheritance to do what they need. The framework forces them to do so in order to protect itself and them.

• Color objects are immutable.

  • Immutable objects in general make stuff easier to maintain.

• Native look and feels aren't part of the framework.

  • You can still create them if you want, and there are 3rd party libraries that do that, but it doesn't need to be in the core framework.

• The application programming interface is single threaded not multi-threaded.

  • Because the developers of the framework realized that multi-threaded UI frameworks are a failed dream.

The philosophy was to code to make the 80% use case easier and the the 20% use case (usually) possible, using additional user or 3rd party code, while making it difficult for the user code to accidentally (or intentionally) break the framework. You just stumbled upon one instance of an application of this philosophy.

There are a whole host of catch-phrases that you could use to describe the reason for this design approach. None of them are OOP or MVC specific. The underlying principles have been around far longer than software engineering, they are just approaches towards work and engineering in general. Here are some links if interested:

• You ain't going to need it YAGNI
• Minimal viable product MVP
• Worse-is-better
• Muntzing
• Feature creep prevention
• Keep it simple stupid KISS
• Occam's razor