2014-07-22 Pietro Martinelli

Seven things I really hate in database design

Common prexif in all table names
eg: TXXX, TYYY, TZZZ, VAAA, VBBB - T stays for Table, V stays for View
eg: APPXXX, APPYYY, APPZZZ - APP is an application name
Common prefix in all field names in every table
eg: APPXXX.XXX_FIELD_A, APPXXX.XXX_FIELD_B, APPXXX.XXX_FIELD_C
Fields with the same meaning and different names (in different tables)
es: TABLE_A.BANK_ID, TABLE_B.BK_CODE
Fields with the same logical type and different physical types
eg: TABLE_A.MONEY_AMOUNT NUMBER(20,2)
TABLE_B.MONEY_AMOUNT NUMBER(20,0) – value * 100
TABLE_B.MONEY_AMOUNT VARCHAR(20) –value * 100 as char
No foreign-keys nor integrity constraints at all - by design
Date (or generally structured data type) representation with generic and not specific types
eg: TABLE_A.START_DATE NUMBER(8,0) – yyyyddmm as int
eg: TABLE_B.START_DATE VARCHAR(8) – yyyyddmm as char
(possible only in presenceof 6.) Special values for semantic corner-cases which are syntactically invalid
eg: EXPIRY_DATE = 99999999 – represents “never expires case”,
but… IT’S NOT A VALID DATE!!! - why not 99991231??

2012-05-29 Pietro Martinelli

Mocking static methods and the Gateway pattern

This post was originally posted here.

A year ago I started to use mocking libraries (e.g., Mockito, EasyMock, …), both for learning something new and for testing purpose in hopeless cases.
Briefly: such a library makes it possible to dynamically redefine the behaviour (return value, thrown exceptions) of the methods of the class under test, in order to run tests in a controlled environment. It makes it possible even to check behavioural expectations for mock objects, in order to test the Class Under Test’s interactions with its collaborators.
A few weeks ago a colleague asked me: “[How] can I mock a static method, maybe using a mock library?”.
In detail, he was looking for a way to test a class whose code was using a static CustomerLoginFacade.login(String username, String password) method provided by an external API (an authentication custom API by a customer enterprise).
His code looked as follows:

public class ClassUnderTest {
  ...
 public void methodUnderTest(...) {
  ...
   // check authentication
   if(CustomerLoginFacade.login(...)) {
      ...
  } else {
    ...
   }
 }
}

but customer’s authentication provider was not accessible from test environment: so the main (but not the only: test isolation, performances, …) reason to mock the static login method.

A quick search in the magic mocking libraries world revealed that:

EasyMock supports static methods mocking using extensions (e.g, Class Extension, PowerMock)
JMock doesn’t support static method mocking
Mockito (my preferred [Java] mocking library at the moment) doesn’t support static method mocking, because Mockito prefers object orientation and dependency injection over static, procedural code that is hard to understand & change (see official FAQ). The same position appears even in a JMock-related discussion. PowerMock provides a Mockito extension that supports static methods mocking.
So, thanks to my colleague, I will analize the more general question “Ho can I handle external / legacy API (e.g., static methods acting as service facade) for testing purposes?”. I can identify three different approaches:
mocking by library: we can use a mocking library supporting external / legacy API mocking (e.g, class’ mocking, static methods’ mocking), as discussed earlier
mocking by language: we can refer to the features of a dynamically typed programming language to dynamically change external / legacy API implementation / behaviour. E.g., the login problem discussed earlier can be solved in Groovy style, using the features of a language fully integrated with the Java runtime:
1
2
3
CustomerLoginFacade.metaClass.'static'.login = {
return true;
};
Such an approach can be successfully used when CustomerLoginFacade.login‘s client code is Groovy code, not for old Java client code.
Architectural approach: mocking by design. This approach refers to a general principle: hide every external (concrete) API behind an interface (i.e.: coding on interfaces, not on concrete implementation). This principle is commonly knows as dependency inversion principle.
So, we can solve my colleague’s problem this way: first, we define a login interface:
1
2
3
public interface MyLoginService {
public abstract boolean login(final String username, final String password);
}
Then, we refactor the original methodUnderTest code to use the interface:

public class ClassUnderTest {
  private MyLoginService loginService;
 // Collaborator provided by Constructor injection (see here for
 //  a discussion about injection styles)
 public ClassUnderTest(final LoginService loginService) {
  this.loginService = loginService;
 }   
 ...
 public void methodUnderTest(...) {
  ...
   // check authentication
   if(loginService.login(...)) {
      ...
  } else {
    ...
   }
 }
}

So, for testing pourposes, we can simply inject a fake implementation of the MyLoginService interface:

public void myTest() {
 final ClassUnderTest cut = new ClassUnderTest(new FakeLoginService());
 cut.methodUnderTest(..., ...);
 ...
}

where FakeLoginService is simply

public class FakeLoginService implements MyLoginService {
 public boolean login(final String username, final String password) {
  return true;
 }
}
and the real, pruduction implementation of the interface looks simply like this:

public class RealLoginService implements MyLoginService {
 public boolean login(final String username, final String password) {
  return CustomerLoginFacade.login(username, password);
 }
}

Ultimately, the interface defines an abstract gateway to the external authentication API: changing the gateway implementation, we can set up a testing environment fully decoupled from real customer’ authentication provider
.
IMHO, i prefer the last mocking approach: it’s more object oriented, and after all… my colleague called me once the more OO person I know :-). I find this approach more clean and elegant: it’s built only upon common features of programming languages and doesn’t refer to external libraries nor testing-oriented dynamic languafe features.
In terms of design, too, I think it’s a more readable and more reusable solution to the problem, which allows a clearer identification of responsibilities of the various pieces of code: MyLoginService defines an interface, and every implementation represents a way to implement it (a real-life (i.e.: production) implementation versus the fake one).

However, method mocking (by library or by language, doesn’t matter) is in certain, specific situations a very useful technique, too, especially when code that suffers static dependencies (ClassUnderTest in our example) is an example of legacy code, designed with no testing in mind, and is eventually out of developer control.
[Incidentally: the solution adopted by my colleague was just that I have proposed (i.e., mocking by design)]

Credits: thanks to Samuele for giving me cause to analyze such a problem (and for our frequent and ever interesting design-related discussion).
Thanks to my wife for hers valuable support in writing in my pseudo-English.

2012-05-21 Pietro Martinelli

testing►java

How to automatically test Java Console

Some weeks ago, during a workroom lesson in University, I’ve faced a typical TDD-addicted dilemma: how can I test driven develop a console-based Java application?
The main problem is clearly how to automatically interact with the application, which relies to System.in for user input and to System.out for user output.
You can use System.setIn and System.setOut methods, of course: but this is IMHO a dirty solution to the console-interaction testability problem, which can be resolved in a cleaner way referring to the dependency inversion principle, ubiquitous in test driven design: rather than directly referring to concrete System.in and System.out streams (this reference is concrete because it’s direct, not because it points to a concrete class: InputStream is actually an abstract class), the console-based application should reference to some abstraction that encapsulates standard I/O streams dependency - for example to Scanner (for user input) and PrintStream (for user ouput: again, direct reference to System.out is concrete because it’s direct, not because it points to something concrete).
So, application behaviour can be encapsulated into a classe having a constructor like this:

1	public HelloApp(Scanner scanner, PrintStream out)

The application main method instances such a class and invokes a method thar triggers application logic execution, simply providing Scanner and PrintStream that wrap standard I/O streams:

public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        scanner.useDelimiter(System.getProperty("line.separator"));
        
        HelloApp app = new HelloApp(scanner, System.out);
        app.run();
}

Testing code, however, can provide to HelloApp testing oriented instances of Scanner and PrintStream:

final Scanner scanner = new Scanner("Duke y Goofy y Donald n");
scanner.useDelimiter(" "); 
 
ByteArrayOutputStream outputBuffer = new ByteArrayOutputStream();
PrintStream out = new PrintStream(outputBuffer); 
 
final HelloApp app = new HelloApp(scanner, out);
app.run();
 
final String output = outputBuffer.toString(); 
// Assertions about outputBuffer content:
assertTrue(output.startsWith("Welcome to HelloApp!"));

So, we have gracefully decoupled application logic from console-based user interactions, providing a solid framework for automated application testing and, even more satisfying for TDD addicted, for Test Driven Development.

A complete example can be found here: https://bitbucket.org/pietrom/automatically-testing-the-console

Code repository can be cloned using git:
git clone https://bitbucket.org/pietrom/automatically-testing-the-console.git

This post was originally published here on 21/05/2012.

2012-04-13 Pietro Martinelli

toolbox

How-to find a class in a JAR directory using shell scripting

This post war originally published here.

The biggest problems in J2EE applications deployment come often from classloader hierarchies and potential overlapping between server-provided and application-specific libraries. So, searching classes through collection of JARs is oftwen the main activity in order to identifiy and fix classloader issues.
This is surely a tedious and repetitive task: so, here’s a shell script you can use to automate JAR collection traversing and tar command’s output analysis to search a pattern, which is provided as script parameter.

Credits: Thanks to sirowain for parameter check and return code related contributions.

#!/bin/bash
# Commonly available under GPL 3 license
# Copyleft Pietro Martinelli - javapeanuts.blogspot.com
if [ -z $1 ]
then
    echo "Usage: $0 <pattern>"
    echo "tar xf's output will be tested against provided <pattern> in order to select matching JARs"
    exit 1
else
        jarsFound=""
        for file in $(find . -name "*.jar"); do
                echo "Processing file ${file} ..."
                out=$(jar tf ${file} | grep ${1})
                if [ "${out}" != "" ]
                then
                        echo "  Found '${1}' in JAR file ${file}"
                        jarsFound="${jarsFound} ${file}"
                fi
        done
        echo "${jarsFound}"
        
        echo ""
        echo "Search result:"
        echo "" 
        
        if [ "${jarsFound}" != "" ]
        then
                echo "${1} found in"
                for file in ${jarsFound}
                do
                        echo "- ${file}"
                done
        else
                echo "${1} not found"
        fi
        exit 0
fi

This script is available on github.com:
https://github.com/pietrom/javapeanuts-shell-utils/blob/master/find-jar.sh

2012-02-28 Pietro Martinelli

coding horrors

Never executed - Never tested

Code samples I’ll publish in this post are not fakes: they come from real code, released into production.
And they are not only brilliant samples of never tested code: they are samples of never executed code!!! Indeed there are in these code snippets execution path which ever - ever! - fail. Read to believe…

Sample #1 - NullPointerException at each catch execution

MyClass result = null;
try {
    result = callMethod(...);
} catch(Exception e) {    // throws ever NullPointerException...
    result.registerException(e);
}

Sample #2: ArrayIndexOutOfBoundException at each catch execution

try {
    result = callSomeMethod(...);
} catch(Exception e) {
    String[] messages = new String[3];
    messages[0] = ... ;
    messages[1] = ... ;
    messages[2] = ... ;
    // throws ever ArrayIndexOutOfBoundException ...
    messages[3] = ... ; 
    throw new CustomException(messages);
}

Sample #3: ClassCastException whenever if‘s condition is verified

public class AClass {
    ...
    public void aMethod(final Object obj) {
        ...
        if(!obj instanceof InterfaceXYZ) {
            final InterfaceXYZ xyz = (InterfaceXYZ)obj;
            ...
        }
        ...
    }
}

2012-02-17 Pietro Martinelli

coding horrors

Reinventing the wheel: Collection.size()

Original way to reinvent the wheel - by an examination of “Programming Fundamentals”

public class MyContainer {
   private final Collection myBag;

   public int getBagSize() {
    int j = 0;
    for(int i = 0; i < this.myBag.size(); i++) {
     j++;
    }
    return j;
   }
}

2012-02-15 Pietro Martinelli

antipatterns

Improper inheritance and light-hearted downcast

This post war originally published here.

And here is maybe the worst design I’ve ever seen - directly from production-released code, of course…

Inheritance is a key feature in object-oriented programming languages, providing support for both specialization and flexible extensibility. But… using inheritance just to use it can drive to horrible design cases, where distinction between superclass/interfaces and different subclasses is improper and extensibility is actually impossible. This is the case of a real-life production code I was lucky enough to see:

public interface InterfaceX {
   public abstract void aMethodX();
}

public interface InterfaceY {
   public abstract String aMethodY(final String s);
}

Class FatImplementation implements both InterfaceX and InterfaceY:

public class FatImplementation implements InterfaceX, InterfaceY {
   public void aMethodX() {
      ...
   } 
 
   public String aMethodY(final String s) {
      ...
      return ...;
   }
}

And… Ladies and Gentlemen… the crazy client class, whose method is casting to InterfaceX an InterfaceY reference, relying on the fact that FatImplementation implements both interfaces:

public class CrazyClass {
 public void theCrazyCastingMethod(final InterfaceY y) {
  ...
  ((InterfaceX)y).aMethodX();
 }
}

This is an improper use of abstraction-inheritance programming model, since the cast succeeds only with a specific implementation (FatImplementation) of given interface and polymorphism is actually not possible - this is actually a wonderful violation of Liskov Substitution Principle.

… … … poorly and foolishly designed, isn’t it? And… what if I said that InterfaceX and InterfaceY, in the original code, where StatefulXXX and StatelessXXX? So… FatImplementation was stateful and stateless at the same time! AAAAAAHHHH!

2012-02-11 Pietro Martinelli

design patterns

Singleton, testing and dependency inversion

This post war originally published here.

Singleton: pattern or antipattern?

Accordingly to Wikipedia, Singleton is a creational pattern, used to implement the mathematical concept of a singleton, by restricting the instantiation of a class to one object. So, it’s a pattern!
But it’s an antipattern, too, especially from the point of view of testing: it’s a (simple) variant of Service Locator testability antipattern.

As states Jens Schauder in his post Fixing the Singleton, there are two key characteristic of the (classic implementation of) singleton:

there can be only a single instance of the class developed as singleton
there is a central, global acces point to the singleton instance

Alhough the first one is the main - if not the only - reason for use of Singleton pattern, it comes almost alway with the second one. But… while the first one is a conceptual feature of the pattern, the second is nothing but an implementation detail!

We can therefore speak of conceptual (semantic) Singleton, when we have a class that can be instantiated only once in the application lifecycle, and syntactic Singleton, with reference to the traditional GoF‘s implementation.
Well, my idea is that you can think of two different basic implementation strategies for semantic Singletons:

Singleton by syntax - traditional GoF’s implementation, through private static instance and public static (and then: global) accessor
Singleton by contract / application - implementation of the concept of “single class instance” without syntactic constraints: application code takes care of respect the contract of “single instance”. Tipically, application infrastructure responsible for creating object and setting up collaborators references instantiates the Singleton class only once and passes created instance to modules interested in its use: this is substantially an application of Dependency Inversion Principle, and can be implemented through Inversion of Control frameworks like Spring and Google-Guice (for a good discussion about self implemented dependency injection, see this article).

The first approach suffers the problem suggested initially: there is a global state, publicly accessible, liberally referenced everywhere in the client code - and you know that global state is evil!
The second one, instead, provides a conceptual Singleton instance without referring to syntactical constraints: application lifecycle infrastructure ensures unicity of the Singleton class instance.

In code:

Singleton by syntax:

package singleton;

public class UIDGenerator {
  private static final UIDGenerator INSTANCE = new UIDGenerator();

  public static UIDGenerator getInstance() {
    return INSTANCE;

  }

  private UIDGenerator() {
  }

  public String nextId() {
    return ...;
  }
}

Client code:

public void foo() {
  String newId = UIDGenerator.getInstance().nextId();
  // Use newId
}
  
public void bar() {
  Account account = new Account(UIDGenerator.getInstance().nextId());
  // Use newly created Account
}

This the classical GoF’s implementation of pattern Singleton: privateconstructor and final static INSTANCE ensure instance unicity, public static accessor provides global access to singleton instance.

Singleton by contract:

package singleton;

public interface UIDProvider {
  public abstract String nextUid();
}

Client code:

package singleton;

public class AccountManager {
  private final UIDProvider uidProvider;

  public AccountManager(UIDProvider uidProvider) {
    this.uidProvider = uidProvider;
  }
  
  public void bar() {
    Account account = new Account(uidProvider.nextUid());
    // Use newly created Account
  }
}

In the second implementation we define an interface for UID generation: application infrastructure (i.e.. in most cases. an Inversion of Control container, like Spring) will ensure that a single instance of a class implementing UIDProvider is passed whenever it’s necessary.

This way we can obtain the semantic part of the pattern without the syntactical one: there is no public static context accessed everywhere, and a reference to the singleton is indeed injected into modules that need it. So, unlike in the first case, it’s possibile to mock UIDProvider for testing purposes (for example because real implementation is time expensive, or there is a fee for every use, or simply because unit testing is isolation testing and we need to make assumptions on generated uid in testing code):

public class AccountManagerTest {
  @Test
  public void testMethod() {
    AccountManager underTest = new AccountManager(new FixedUIDProvider());
    // Exercises underTest
  }
}

This is IMHO a more, more (more!) powerful approach for implementing singleton than the classic one: can you figure out how to mock UIDGenerator.getInstance().nextId() calls?
The basic idea behind this proposal is a variation of single responsibility principle: classic singleton implementation drives to classes that implement two responsibilities: a functional responsibility - what the class do - and a structural responibility - how is the class instantiated and the instance accessed. Inversion of Control containers, and more generally the idea of Dependency Inversion, support separation of responsibilities by divide functional code and object graph lifecycle management code: this leads to clearer, simpler design, that decouples singleton implementations from client modules and supports testing in a more effective way.

2012-02-01 Pietro Martinelli

Manifesto - Reasons for a blog

I am a serial reader: I read tens of thousands of pages every year. I read novels, comics, essays about mathematics and sciences. But my job is Software Engineering, so I read plenty of books, articles, blog posts and wiki pages about this topic.
And I am a serial polemicist: against what I read, against my and other’s mistakes in coding and design.
So, after much reading and arguing, I feel it’s time to give something back: this blog is intendend to provide a place for my technical thoughts, reasoning, and for the way I feel about Software Engineering.
Some posts will be a kind of repetition of contents already published in the old, defunct blog of the Java User group of Brescia - requiescat in pace. Some posts will be a re-edition of contents, articles, code snippets, and so on, already published on my own wiki: I feel a blog is a more powerful and easy-to-follow kind of communication (you can ultimately simply register my blog’s feed in your feed-reader of choice, and you’ll be notified when I add a new post), so my intention is to migrate all content from the wiki to this new virtual place.
And there will be obviously new posts and new contents, too: code snippets written by me, technical debates about patterns and anti-patterns, coding horrors I run up against during my teaching at University (and not only…), thinking and reasoning at coffee dispenser, technical books reviews, links to posts and various resources in the web. Something about everything and everything about nothing: small - and hopefully tasty - contributions, just like peanuts.
And now: it’s time to write! Stay tuned!

JavaPeanuts logo