Is is acceptable to create mediocre code now in preparation for new language features? [closed]

I’ll be specific: Java 8 is promised to bring lambda expressions as well as method and constructor references among other things. As a Java developer I’m super psyched about that.

In my day to day programming I see more and more opportunities where using these features would greatly simplify code that would otherwise be very verbose and tedious. In lieu of method and constructor references I started using more and more reflection and plan to migrate those code paths to Java 8 as soon as possible. I use special comments (like the well known TODO comments: JAVA8) that can be used by the IDE or grepped easily in order to find the relevant places. I also test all those cases extensively to make sure they work.

But still I have to wonder whether it’s good to do it like that. Is it acceptable to produce a little more brittle code now that will eventually become robust again? GA for Java 8 is September 2013 so it’s not too far in the future (provided the release date doesn’t slip).

A kinda general example would be something like this: I want to create some container objects and fill them with data from a database. If I were to use the standard Java approach, it could look like this:

class ContainerService {
  private Database database;
  private final Map, ContainerInitializer> INITIALIZERS = new HashMap();

  {
    INITIALIZERS.put(Foo.class, new FooInitializer());
  }

  public Container getContainer(Class cls) {
    return INITIALIZERS.get(cls).create();
  }

  interface ContainerInitializer {
    Container create();
  }

  class FooInitializer implements ContainerInitializer {
    Container create() {
      return new Container(database.getFoo());
    }
  }
}

The reflective code is

class ContainerService {
  private Database database;
  private final Map, String> INITIALIZERS = new HashMap();

  {
    INITIALIZERS.put(Foo.class, "getFoo");
  }

  public Container getContainer(Class cls) {
    Method m = Database.class.getMethod(INITIALIZERS.get(cls));
    return new Container(m.invoke(database));
  }
}

Note how all the intermediate interfaces and classes fall away.

The Java 8 variant is something along the following lines:

class ContainerService {
  private Database database;
  private final Map, ContainerInitializer> INITIALIZERS = new HashMap();

  {
    INITIALIZERS.put(Foo.class, database::getFoo);
  }

  public Container getContainer(Class cls) {
    return new Container(INITIALIZER.get(cls).create());
  }

  private interface ContainerInitializer {
    Container create();
  }
}

This is slightly longer again but has type safety. Also it’s trivial to get from the prepared code to the final code using method references.

Of course the example is a bit simple. Imagine having a lot of types the container could contain. In the first method, there would be an extra class for each of them. In the other two methods, only data has to be added. It keeps everything so much simpler.

Don’t fall for the chant of sirens.

Their song talks about new features and performance improvements, but all you get by listening to that, is a neverending stream of pain, delays, procrastination, and deployment woes.

Write for what exists. The rest is mere speculation.

I agree with @ZJR’s answer, but if you want to go ahead you can probably encapsulate this into a MethodReference class of some sort. With luck you might be able to gain type safety by juggling just one place when Java 8 comes along.

Boost basically does this before C++11. Certain features closely resembles the proposed syntax for C++11 to ease transition.

I share ZJR’s opinion that you should stick to what is available today and develop for Java 6 or 7, if that is what you are using now: always use the tools that you have now for what they are, not for what they might be in the future.

I would add that if you really like anonymous functions and other functional-language idioms, you should consider switching to Scala, Clojure, or another language that already exists and fully supports such idioms, instead of waiting for Java to support a few of those idioms some time in the future. Otherwise, when you have your nice lambda expressions in Java 8, you might learn about pattern matching and start missing that (maybe you will get it with Java 10?) And then you will hear about currying or richer type-inference features, and will have to wait again.

So, I would stick to Java 6 for doing your object-oriented programming and switch to a language that truly supports functional programming if you wanted to do proper functional programming or a mix of object-oriented and functional programming. In other words, don’t stick to Java if this language is not providing the combination of features that you are looking for.

And I also agree with “Don’t fall for the chant of sirens.”: I think Oracle is introducing some FP into Java (among other reasons) to keep selling Java to people who are not really interested in FP (otherwise they would be using a real FP language already) but do not want to be considered uncool for not knowing FP.

In my opinion, it is perfectly OK to stay out of this hype and continue to use purely object-oriented languages (like Java 6) if one feels comfortable with them. And if you write proper object-oriented code, it will not be “mediocre code”.

I think the answer to this question most likely depends upon the situation in particular which you’re dealing with. In terms of “day to day programming,” does this consist of your job? Hobbyist/personal work, perhaps? If it’s the latter, I don’t necessarily think it to be a poor idea to look ahead in regards to refactoring and improving your code base, if you have the time — attempting to improve upon your own work is never a bad thing. On the other hand, if it’s a work scenario, even if you’re a project manager you’d still have to run such thoughts by your peers to get their input. However, because these features don’t exist yet, unless you have nothing else on your plate, it could be a very large waste of time and resources because none of the features really exist.

It’s certainly something to think about, and there are a few ways in which you could handle it. You mention being able to make use of TODO comments where Java 8’s features could be applied. You could also consider branching/forking a project entirely and writing makeshift pseudocode (assuming that the lambda syntax in Java 8 isn’t finalized yet) in places where you might want to improve it in the future. Again, though, it brings up the aforementioned concerns of time and effort.

Filed under: softwareengineering - @ 19:41

Thẻ: language-features, programming-languages

Thiết kế website giá rẻ

Danh mục

Is is acceptable to create mediocre code now in preparation for new language features? [closed]