Sunday, March 15, 2015

Motivation

I've been looking at the problem of dynamic properties in Java. Typically properties are injected into a program at start and never change. Common examples include timeouts, host names, etc. Changing these requires and edit and restart (edit can also mean an update to a remote data source).

What I want is runtime updates to properties, and the program uses the new values. Hence "dynamic properties".

There are several schemes for this built around frameworks or external data sources. I want something using only the JDK.

Interfaces

My interfaces became one for tracking key-value pairs, one for updating them (javadoc munged to display in post):

Thread-safe, not concurrency-safe (lost updates, etc). Fine if properties are not updated on top of each other (i.e., several in the same microsecond)

I expect it to be straight-forward to integrate into JSR107, Cassandra, etc, but I've not tried this from home

And offered some advice to my juniors:

Be functional where sensible, the benefits are almost beyond enumeration

Corollary: Avoid state - in Java that means fields. Temp variables (locals) are debatable and come down to individual taste. I lean to avoiding them, but there's nothing wrong with creating locals that clarify the code for others (including yourself 6 mos. later)

Wednesday, March 04, 2015

Refactoring software, that is, restructuring existing source code to make it more readable, efficient, and maintainable, is something all developers do every now and again. Of course, the implicit assumption behind refactoring is that the benefits (time and headaches saved in the future) outweigh the costs (time and effort spent now). However, new experimental research suggests that this may not be the case and that software code quality may not be improved much, if at all, by refactoring.

The researchers selected a small-scale application (about 4,500 lines of C# code) used by the academic staff at the University of Kelaniya for scheduling events and managing online documents for evaluation. 10 common refactoring techniques were applied to the code (e.g., Replace Type Code with Subclasses, Replace Conditional with Polymorphism).

Reading the press account I expect objections such as:

C#?

Well, language should not matter here

Too small an example!

This is a fair complaint, the impact of refactoring scales with code base size

Those weren't professionals

The reviewers were a mix, but this complaint overlooks how much code is written and maintained by "non-programmers", an oxymoron as programming is an activity, not a type of person

My own objection is that the refactoring did not go far enough. Deepening a type hierarchy does often make code "worse", delegation is often a better choice than inheritance. In a larger code base than the sample used, this become more obvious.