Object-Oriented Design vs. Persistence

From time to time I attend discussions about OOP. Every time someone come up with the argument of dealing with persistence. The typical question can be reduced to should an object persist itself or rather be persisted? I believe the question is fundamentally wrong.

SOLID Principles in Java by Example

There are a lot of articles about the SOLID principles. But usually a different example for a particular principle is to be found. Instead, would it be nice to demonstrate all of them on a single code snippet?

How to Test Abstract Classes

Abstract classes typically offer one or more concrete methods. These must be tested as well. There are several ways how to do it, but which one to choose?

Treat Data as Data

Object-oriented approach is a mighty concept making software more maintainable, which means cheaper and easier to understand. Problems come at boundaries, where objects have to be passed on into a different layer or another system. There, the objects become just data and should be treated as that.

Keep Test Code inside the Test

Noone wants to write one thing twice. Reducing duplicates makes code shorter and clearer. How much this applies for test code?

How I do TDD

I really like Test-Driven Development (TDD) and apply it almost always. The problem with TDD is that it focuses too much on working software.

Domain-Driven Serverless Design

One reason I really like the serverless architecture approach is being pretty selfish: one has to care only about what matters - the code. Well, I know code is not everything, but as a developer I'm just having more fun coding than scripting infrastructure in YAML or similar. For people like me is the serverless model a dream come true. But how to do serverless without turning the dream into a nightmare?

Don't Share Data among Threads

Distribution of a task among several threads means horizontal scaling - the more computing resources (processors) the less time to work the task out. Sharing data among threads brings the need to synchronize which kills the scaling capability of the computing. How to proceed when shared data are needed?

Double Testing

Write your tests once and run them twice - as both unit and integration tests - sounds like a good deal, let's take a look at this practice.

Glass-Box Testing Doesn't Need Mocking

Black-box testing is testing of a component via its API without any knowledge of its implementation details. As the opposite there is the white-box testing. And it about testing implementation, right? Well, no...