Architecture & Design

Explicit access permission design with user roles

Most applications need access control and must therefore implement user permissions is some way. In a lot of the projects my colleagues asked me how I would implement user permissions. Since a lot of them found my thoughts an interessting way of implmenenting user permissions I want to share my thoughts here with you too. Maybe you can benefit from some or all of them or even create a completely new design. Annotation based permissions Usually you will implement permissions using annotations, but there are pitfalls and issues common to all annotation bases permissions. Annotation based user permissions code will often look like this: @Roles(“admin”) public class SomeClass { public… Read More »Explicit access permission design with user roles

Make method pre-conditions explicit by design

A method usually makes assumptions about the arguments that are passed into it by a method invocation. The conditions that the arguments must fullfil are named the method’s pre-conditions. Thus a good method implementation checks if the arguments are in an expected state so that the method can execute. Often developers use basic data types as method parameters like String, Integer and so on, but a method usually doesn’t allow every possible value that these types can take. E.g. a method might declare an integer as parameter, but only accepts positive integers. Such a method might validate it’s pre-condition in this way: public double divide(double dividend, double divisor){ if(divisor == 0){ throw new IllegalArgumentException(“division by 0 is not… Read More »Make method pre-conditions explicit by design

Progress Object Pattern

When a user executes a long running background task an application usually wants to report progress about the task to the user. Application developers often do this by passing a ProgressListener to the background task’s  method and the method uses the ProgressListener to report it’s progress. But you can also design it in another way and I would like to introduce another pattern here. At least I would like to show an example of how to implement a progress object pattern with Javas Swing. The complete example code is available at gitthub: https://github.com/link-intersystems/blog/tree/master/progress-object-pattern. But before I introduce the progress object patten let us take a look at the progress listener concept. Progress listener A progress listener is conceptually a callback that… Read More »Progress Object Pattern

A plug-in architecture implemented with java

Instead of building monolithic applications developers prefer modular and extendible applications. Either they want to use the flexible architecture by themselfs or provide a plug-in api for other developers. In both situations one must define a modul’s purpose and it’s boundary. This module boundary is also called the service provides interface (SPI) or also a plug-in api. Java’s jar file specification describes how service providers can provide their services so that others can lookup them. This pattern is known as the service locator pattern. Since Java 1.6 the ServiceLoader has been added in order to make service provider lookup easy for application developers. Prior to Java 1.6 applications developers had to implement the lookup on their own based on the jar… Read More »A plug-in architecture implemented with java

Enums as type discriminator anti-pattern

In Java 1.5 enums were introduced to ease handling of constant values. Enums can improve code quality, because they are types that the compiler can check. But they can also be misused and lower the code quality. In this blog I want to discuss the misuse of enums as type discriminators and show you why this kind of usage is an anti-pattern from an object-oriented perspective. Type-switches What I call a “type-switch” is just any conditional statement that does type checks in order to execute type specific code. Here are some examples of type switches. HumanState humnanState = …; if(humanState instanceof HappyState){ singHappySong(); } else if(humanState instanceof SadState){ singDirge(); } HumanState humanState =… Read More »Enums as type discriminator anti-pattern

Singleton implementation pitfalls

In this blog I want to show implementation pitfalls of the singleton pattern and show you why enums are the better singletons. The singleton pattern is widely known and discussed a lot of times. Developers often prefer to implement a singleton using a final static field. But this approach has some pitfalls or rather malicious code can compromise the singleton pattern. In the next sections I will show you the possible attacks on singleton implementations that compromise the pattern. Maybe you will use this techniques to implement a kind of workaround some day, but I hope you will not. Static Final Field Singleton The purpose of a singleton is that only 1 instance of a… Read More »Singleton implementation pitfalls

Instanceof vs. polimorphism

An instanceof check is often an indication for misplaced source code. Some developer say that instanceof checks are ugly code, but there are reasons against instancof checks beyond a subjective feeling. In this blog I want to compare instanceof checks with polymorphism and discuss the downsides. This blog is intended to be used as a basis for desing decisions and discussions about code design. Instanceof motivations Everytime we write an instanceof check in java we are interessted in the capabilities of an object. We want to know if an object has specific features or methods or if it has not. This can also be implicit features that are derived from the type. In this case we have 2 options: Introduce… Read More »Instanceof vs. polimorphism

Bugs love logging to hide

A lot of projects run integration and unit tests, but often miss a little something – logging. When you use logging you often check if the log level is enabled or not before you log. But this means that you introduce a control flow statement that enables or disables some code. So if you miss to enable logging for your tests you let code untested and bugs love untested code, because they can hide there. But it is easy to remove this hiding places for bugs. Avoid log level checks if possible If you can avoid log level enabled checks, you avoid control flow statements and this  means that you remove hiding… Read More »Bugs love logging to hide

Stateless Rest Service Authentication

REST Services are considered stateless. Therfore a Rest Service must not hold any client state. If so REST Services can be scaled easily by adding new server nodes without to worry about session replication. But this also means that a REST-Client must send all authentication information with every request. There are several techniques to handle that and each of them has it’s pros and cons. This blog wants to discuss some different approaches. Why not just using stateful application services? The simplest way to implement authentication in an application service is to make it stateful. This means that the application service is aware of requests that the client made before some request. Therefore… Read More »Stateless Rest Service Authentication

A type-safe named query design approach for JPA

The starting point In a JEE you normally use the Java-Persistence-API JPA to access the data. JPA provides named queries which are statically defined queries with an unmodifiable query string. Because the query string is unmodifiable a client must still be able to provide parameters that concretize a query. Those query parameters are placed in the query string in a special format, e.g. :username. So if we define a named query in the simplest way it will look like this: @Entity @NamedQueries( { @NamedQuery( name = "findOrdersByUsername", query = "select distinct o from Order o JOIN order.user AS u where u.username = :username") } ) public class Order { ...… Read More »A type-safe named query design approach for JPA