Java, Programming, Software

Programming to Interfaces Anti-Pattern

Here’s a personal bete noir. Interfaces are good m’kay? They allow you to separate function and implementation, you can mock them, inject them. You use them to indicate roles and interactions between objects. That’s all smashing and super.

The problem comes when you don’t really have a role that you are describing, you have an implementation. A good example is a Persister type of class that saves data to a store. In production you want to save to a database while during test you save to an in-memory store.

So you have a Persister interface with the method store and you implement a DatabaseStorePersister class and a InMemoryPersister class both implementing Persister. You inject the appropriate Persister instance and you’re rolling.

Or are you? Because to my mind there’s an interface too many in this implementation. In the production code there is only one implementation of the interface, the data only ever gets stored to a DatabaseStorePersister. The InMemory version only appears in the test code and has no purpose other than to test the interaction between the rest of the code base and the Persister.

It would probably be more honest to create a single DatabaseStorePersister and then sub-class it to create the InMemory version by overriding store.

On the other hand if your data can be stored in both a graph database and a relational database then you can legitmately say there are two implementations that share the same role. At this point it is fair to create an interface. I would prefer therefore to refactor to interfaces rather than program to them. Once the interaction has been revealed, then create the interface to capture the discovery.

A typical expression of this anti-pattern in Java is a package that is full of interfaces that have the logical Domain Language name for the object and an accompanying single implementation for which there is no valid name and instead shares the name of the interface with “Impl” added on. So for example Pointless and PointlessImpl.

If something cannot be given a meaningful name then it is a sure sign that it isn’t carrying its weight in an application. Its purpose and meaning is unclear as are its concerns.

Creating interfaces purely because it is convenient to work with them (perhaps because your mock or injection framework can only work with interfaces) is a weak reason for indulging this anti-pattern. Generally if you reunite an interface with its single implementation you can see how to work with. Often if there is only a single implementation of something there is no need to inject it, you can define the instance directly in the class that makes use of it. In terms of mocking there are mock tools that mock concrete classes and there is an argument that mocking is not appropriate here and instead the concrete result of the call should be asserted and tested.

Do the right thing; kill the Impl.

Standard
Java, Web Applications, Work

Better, Faster, Weaker

I went to the Developers and Startups Meetup last week (look it up on Meetup if you’re interested it was a good event). One thing that struck me was that all the entrepreneurs were mostly interested in PHP and Ruby on Rails (there was a significant rump of ASP and .Net which I can only put down to C#’s language hotness at the moment). Java in particular was poorly regarded.

I was intrigued by what was causing the negative vibe as while I can understand that Ruby on Rails is the new tech hotness I couldn’t really see the appeal of PHP over something like Java that has a decent stack that is practically free. Talking to a few people I got the sense that PHP was seen as a “getting things done” language. Something that got you to a tangible real product very quickly. Rails seemed to have much the same quality but I think a lot of people felt that Rails skills were more expensive and in a lot of cases they wanted a thin web layer over an existing service backend that already existed.

Of course both PHP, Rails and the Java Web Stack all make various compromises to do what they do. Where Rails is opinionated, Java probably isn’t opinionated enough. If you put all your code into page (Model 1 stylee) then I’m pretty certain that writing JSPs in J2EE 5 is probably as quick to put something together.

Of course one thing that hugely hampers Java as a productive web stack is the compile and deploy loop. There is none of the immediacy of something like RoR that allows you to make changes very quickly in response to feedback. The tradeoff is of course that the code needs to be interpreted and you have to add some kind of caching to avoid the performance hit of always having to evaluate code.

But given that there are a group of people who need to have code quickly so they can sell something to their customers or investors and that they are willing to make all kinds of compromises about scale and maintainance costs is the Java platform really out of the question? I ask this because I think I have been involved in quite responsive Java web teams where feature changes have been matters of days not weeks or months.

I think that perhaps the issue is partially just mental. Enterprise software development tends to take place in a risk-adverse environment where certainty or process is valued over rapid delivery. “Best practice” in this environment tends to sacrifice timeliness. In the smaller business space this might well be a practice turned into dogma.

That said though some Java Frameworks introduce major barriers to just getting stuff done. Any framework that forces you to produce XML based interaction flow is probably distracting you from generating functionality that people want and will pay for. Routing isn’t a trivial part of an application but that’s all the more reason to box clever with it. Any framework that doesn’t make it simple to inject services into classes is making life too hard. Ditto any framework that forces you to work with a particular Expression Language or Templating product.

I am wondering if what I am looking for is actually the weakest Java framework. Rather than having functionality for all circumstances (and having to configure and setup it all up) I want a very basic REST framework which I can then add templating and persistence according to my need. It still wouldn’t have the nice scaffolding of RoR but it would mean that each element of the web app would be absolutely vital to its function. Weakness would generate the power of vitality and reduce the obfuscation of bloat.

Standard
Groovy, Programming, Software

Using Gant to build Java Projects

I know I said I would be taking a step by step introduction to Gant in my last post on the subject but sometimes the devil drives and you need things done in a less systematic way.

Recently I have been building Java and Scala projects with Gant. I think it has been a successful exercise so I am just going to jump on and show you some example buildfiles. The first one is going to be a Java project. This project is obviously toy code but I think if you just download the sample project and start filling in your own code (it’s an Eclipse project, Intellij and NetBeans should both import it successfully) you will be happy with how little you have to change the build file.

First have a look at the Gant file itself and then I am going to talk about the things that I think make Gant such a powerful and productive tool. The first thing to point out is the line count, this represents a complete build file for a Java SE project in under 100 lines. That includes the Hello World target I’ve left in as an echo test. Gant might have a slightly weird syntax if you are unfamiliar with Groovy but it isn’t verbose.

Targets and dependencies were in the last post so this time the new thing is using AntBuilder. Any method call that starts with Ant is a invocation of an Ant task. These are nothing but thin wrappers around the normal Ant task (and in fact I usually write them using the Ant Task documentation). Things that are attributes in Ant XML become hash properties in the parameter list. Things that would normally be nested elements are calls to the enclosing builder.

One area where Gant wins big is the way you can mix normal variables, Groovy string interpolation and Ant properties. Declaring the directory paths as Groovy variables near the head of the file allows me to create new paths via interpolation and assign the variable to the properties of an Ant task. Ant XML has properties and macro interpolation but this is both clearer and easier.

I am also using the Gant built-in clean task and in the course of using it, Groovy’s operator overloading for lists. I’m not a huge fan of operator overloading but if it’s clear enough here then it is great to have a DRY list assignment.

I also like the way that the directories are created in the init task. This kind of closure looping over a list again shows some of the power and conciseness that can be achieved by a language rather than a configuration file. If you don’t read Groovy then the each method iterates over the list its attached to and each item resulting from the iteration is stored in the whimsical “it” local variable.

Standard
Java, Programming

Factory of Factories

I am convinced that Patterns are the new Anti-Patterns. As the joke runs, the GoF patterns show you how to write better C++.

One Pattern/Anti-Pattern that drives me up the wall are Factories. Or as the might often be better known: Constructors. After all if a Factory only constructs one type of thing it is no better abstraction that just putting the construction logic in the damn constructor.

Effective Java makes a better suggestion for Java coding that constructors like inheritance should be used sparingly. Instead of creating a whole new class for constructing instances just create static factory methods inside the class with appropriate names for the kind of construction being done.

This is neater, keeps related code closer and applies in a lot more situations. My rule when evaluating code is that an implementation of Factory actually has to create more than one type of object in a way that cannot be replicated by Dependency Injection to have value.

Not much code passes that test, not even my previous attempts to please the structural aesthetic of enterprise architects. In the past I have been as guilty of pattern abuse as anyone.

Standard
Java

Ooo JPA, JPA

I normally have nothing good to say about ORM so I had a pleasant surprise today when I was able to generate four One to Many object relationships in about four or five hours.

I’m currently using TopLink although I try to stick to space inside the standard and avoid getting dragged into vendor extensions. I actually prefer OpenJPA from a testing point of view as TopLink won’t seem to play ball unless there is a persistence.xml in a directory called META-INF at the root of your classpath.

The basic syntax is pretty simple, you create a field that is a Collection of the Entity that represents the other side of the relationship, I used a List but then wondered why I had done that. You then annotate that field with @OneToMany and then specify the Join mechanism. Now this is where it usually gets messy and I have to say there is a certain amount of gnarl to this one. I had a relatively simple Join Table on the go but thankfully the annotation @JoinTable needs to know only three things.

Firstly the name of the table (as per the @Column annotation) and then the JoinColumns and InverseJoinColumns parameters. These names are correct but probably seem fiercer than they need to be. Both parameters take an array of @JoinColumn annotations (nested annotations! a first for me). Even if you just have one, wrap it in curly braces. The @JoinColumn syntax is the same as that for @OneToOne and specifies which column to resolve the @Id lookup with.

Join Columns identify the Id of the entity that has the Collection field; this class in other words. The InverseJoinColumns identify the Ids of the other entities that exist in the relationship.

So if Foo has a Collection of Bars then JoinColumns identifies the database columns that contain the Ids of Foo and the InverseJoinColumns identify the Ids of the Bars.

To be honest TopLink has decent enough logging that you can usually muddle along coredumping the SQL that the annotations are building up. My worst mistake was mixing up the @Table annotation with that that of @JoinTable and trying to select from my join table joined with, my join table.

The nice thing is that I was able to very quickly build up four foreign key relationships, all using join tables (some of which had been badly denormalised) and all by annotating the POJOs that also serve a domain purpose. I had to add some Setters for testing purposes but apart from that if I wasn’t using the data in the application I didn’t have to describe it in the configuration.

Good work JPA!

Standard
Java, London, Programming

London Scala User Group Meeting

Had a good meeting (I thought anyway) at the TW offices that featured a talk from Jamie Webb introducing Scala and then a quick dojo. Scala has a much terser syntax than Java but I managed to do my classic thing of mixing my languages and putting my constructs in the wrong place. The other thing that doing rather discussing taught me is that Scala’s constructor syntax is much better defined than Java with the default constructor going into the declaration of the class. That’s the kind of improvement on Java that I really like in Java. It seems to distill all these lessons you’ve been learning if you write good Java code.

The pub after the event also saw a lot of discussion, there was quite a bit of discussion about testing and dynamic versus static typing. Personally I have decided to follow Neal Ford and reject the issue. To me both Ruby and Scala are low ceremony, high essence languages that choose different approaches to address the same issue. As such I don’t think there is any contradiction in liking and wanting to learn both languages.

Similarly I love compile time checking but I’m not giving up on testing. It’s a synergistic practice and I want to get the benefits from TDD/BDD/Tests as Specification. To me there is some irony that if I do have a test suite then actually I have more flexibility about my choice of languages. Not testing means you get much higher value from strong compile checking and therefore something like Scala is going to deliver much more benefit quickly. At the end of the day though I don’t want to have treat my tests as the gamekeeper of my wild code. I do expect the language and the compiler to give some structure and help to the development process.

Despite (because of?) my mistakes  want to do some more and I think Aaron (the founder of the group) suggested converting an existing Java program to Scala. That seems pretty sensible and I have an old Java program that I use a lot hanging around that needs some TLC.

If you are interested in Scala and in London I would recommend coming along to this meetings because you have the chance to meet and talk to everyone who is really engaged in Scala in the city. And to the guy who came all the way from Belgium; I salute you, you are a real hero!

Standard
Java, Programming, Web Applications

Notes on NetBeans 6.1

I am working on an exciting web prototype project at the moment and I am using NetBeans 6.1 rather than my usual Eclipse environment. Overall I am very happy with the experience. The good points are:

  • NetBeans seamlessly integrated with my existing Tomcat instance, configured it correctly and makes it easy to build and deploy my application making my build-compile-deploy cycle as quick as it has ever been
  • The Javascript support is excellent and allowed to discover the JQuery API with no problems
  • It has been easy to define libraries and have them brought in to the project
  • The built-in XSLT validation and one-click transform of a test file is really powerful and very simple to use
  • Associating a web project with different deployment servers is easy
  • The GUIs for writing Java Web App configuration files is great
  • Managing NetBean Modules is easy and the interface is good
  • NetBeans 6.1 is fast, really noticably faster than 6.0.1

That is a whole lot of positive, so what hasn’t been so good?

  • Code templates complete on a different keystroke to code completion. The seperation doesn’t make sense to me. Both things are about completing what I have typed.
  • The window of opportunity for completing a code template is too narrow. If you don’t complete while typing the template stub then it doesn’t work.
  • When entering the parameters of a generated method you have to hit return too much. If the auto-generated code has aready correctly assigned variables to the parameter position then I’m done. At the moment though you have to hit return for each parameter otherwise the code generator gets in a tizzy and often opens brackets on the line below the current method.
  • Really gnarly HTML can take a long time to parse for the navigator windows and the slowdown is noticeable across the whole IDE. XML blazes by comparision.
  • There’s a lot of magic going on to make the project work automagically and there isn’t a good “raw” representation of the project that would make it easy to work from CI and the command-line.

Essentially most of these problems are to do with the interface being too fussy and in some cases too specialised. However I do thing I am getting the benefit of the integrated development environment and while it may not be as fast as Rails it is some of the fastest Java web development I have ever done.

Standard
Programming, Ruby

Synthesis: decreasing tests, increasing reliability

George Malamidis gave a talk at Ruby Tuesday last week about Synthesis which is a kind of mock verification framework. It was the second time I have heard George talk about Synthesis but I really didn’t get it first time (partly due to a pointless debate at the first talk about functional testing (interesting but irrelevant)). A different environment and it just zinged into place for me.

Synthesis ensures that if you mock an interaction between two collaborators you also have a non-mocked test for the method calls in the collaboration. In short it shows when you have stopped unit testing and started testing your mock framework.

Like most people at the talk I could see immediately how that would lead to less worrying about mocking and the good news is that Java port is being worked on.

I wonder if the issue will arise in the Geek Night on Wednesday?

Standard
Java, Software

Jude, the Java Documentation Browser

I recently bought a license to Dave Flanagan’s Jude. I have enjoyed Dave’s books on Javascript, Ruby and of course the Java in a Nutshell series. I was a little disappointed that the Nutshell Java book didn’t get an update to reflect Java 6 and looking for more information I took a trip to Dave’s site and saw an updated version of Jude. I had tried it before but preferred the paper version of the book (it’s initial sections on Java features are still models in the genre).

However with no new edition in the offing I decided to buy Jude and process my Java 6 JDK. Jude basically reads the Javadoc and code in the target JDK and then serves that information out via an in-application HTTP server which you point your browser at.

Recently I have been switching between several “post Java” languages: JRuby, Groovy, Scala and Jython. In all of them though I have needed to know what exactly the details of the Java Library API are so I can access them via the host language. The other day I was filing a bug report and needed to know the details of the Charset object, as I was flicking between between Jude and the report I wondered, “When did this app become indispensible?”.

It might be argued that all you need is Google and the Sun Javadoc but Jude has a few features that make it much more useful. Obviously it useable offline, that’s not something to be sniffed at. Secondly its search and browsing features are intuitive and “right” for the domain. I find it a lot easier to browse through hierachies and leap between classes and packages using Jude’s dedicated tools than via Google. It has also replaced the not inconsiderable heft of Java in a Nutshell from my work bag.

If I could make one change to make it even more useful I would make the default search much more liberal than it is now. The search accepts Java RE which is great for power using but you shouldn’t have to enter /.*http.*/i to find every instance of a class with any variation of HTTP in it, you want to be able to just type “http” Google-style.

Standard