Any self-respecting programmer must have a blog post about unit testing. There are many approaches to write unit tests, but I’ll focus on writing tests for EO code, where objects are immutable, sealed and behavior-based. These restrictions make unit-testing much easier than testing procedural code with DTOs, getters and mutable states. The only thing that an object oriented test should verify is the correct behavior of an object with the provided testing state (fake state). However, the procedural test (I mean the test for procedural code) should verify the data of class instance after some manipulations with injected mock objects for simulating behavior.

Objects use data messages to communicate with each other. It means that object methods can accept some data, but data structure sometimes is too complex. When complex data message is designed wrongly it tends to reduce maintainability because it becomes harder to test this code, and harder to read and understand it. Many people use DTOs for object messages, just because it’s easier to implement, but this code will be less readable in future and has a lot of hidden drawbacks, e.g. broken encapsulation. Instead of this, data languages should be used for complex data structures. It moves data definitions from source code and lets the code encapsulate the data and concentrate on the object’s behavior.

Java generic types are not true types actually, so it’s not possible to have few constructors to accept same type with different generic parameters, because it will have same signature. For example if you need to accept Iterable<String> and Iterable<Text> in constructor, you can’t just add two constructors for these types, because it won’t even compile. In this post I’ll show you how I usually deal with this situation.

Previously, I was speaking about Docker build automation with Rultor, where I explained how to build docker-images and push them to registry after release approve. Now I’ll show how to deploy these images to staging environment of Kubernetes cluster with one comment on GitHub ticket.

Each object in java has two methods to check object equality: it is Object.equals(Object other) and Object.hashCode(). Often developers override these methods so they can store instances of Object subclasses in hash-based collections e.g. HashMap, HashSet etc. I don’t like this design where each object can be compared for equality with any other object, but in this post I’ll not criticize it, rather I’ll try to demonstrate how to implement it correctly for object oriented code.

We have a lot of caching libraries for Java, just take a look at guava or apache-commons JCS. But I don’t really like them because of procedural caching approach, this is why I started new caching library for OO code, here I’ll try to explain main ideas.

Rultor is a great bot to automate development life-cycle: just post a comment in a GitHub ticket and your project will be released. Also it can merge pull-requests and deploy code to production but now I want to speak about how to release a Docker image.

How to split platform depended views from domain logic and be able to unit-test them separately? There are few ways to do it, one of them is MVP (Model-View-Presenter) pattern. It gives us many advantages in Android system but has one major drawback in OOP world - a presenter.

Let’s speak about common domain objects and how they are usually implemented. The tendency here is to define a bunch of accessors to share object’s state and returning nulls as an indicator of empty value. In this post I will try to refactor one of this objects to fully encapsulated one!

It’s an open secret that almost every Android application stores something in a database. Nearly always it is SQLite.
In my practice I’ve tried many ways to work with sqlite in Android: it was some ORM and active-record libraries, ContentProvider’s, even some wrappers for native .so libraries. But with none of them I was satisfied.