The consequence of using Test Double

”With great power comes great responsibility”. This quote of Uncle Ben was and is with Peter Parker through all his career as a Spider-Man. It was used to describe how we should handle with difficult situations in our lives and that each choice we make can have an impact not only on ourselves, but also on many other people. I think that quote should be the sentence that each developer will repeat all over again. Just a sec before he/she will starts using Test Double (TD). Because TD gives as the great power which allow us to control everything around tested unit. And yes, it makes everything easier, but as Einstein said: “Everything should be made as simple as possible, but not simpler.“.

Each choice you made while you were deciding whether to use or not TD has impact on tests readability, code coverage, tests value, ease of introducing changes or doing refactoring. Each choice you made has impact on your team mates and probably even on those developers that you don’t even know yet.

That’s why we have to made our choices conscientiously and carefully.

That’s why it is so important to have as wide knowledge about used tools and techniques as possible.

Differences between abstract class and interface

it is obvious, right?

No, it’s not. I have conducted a lot of interviews and very often one of the first questions I used to ask was the one about the differences between interface and abstract class. And still I met a lot of programmers who couldn’t give me the right answer.
In my opinion even a junior programmer should know them, maybe not necessarily with understanding what reasons lie behind, but still ­­­­­- structural differences, specific for particular language (and the same for almost all OOP languages) should be more than known.

What do I find instead? Candidates who were applying for other positions (sometimes even senior ones) who didn’t knew the differences or knew only a few or one.
I know that only the things that we know very well are easy, but those are OO basics and we have to know them to write well-designed code.

What’s the deal with serialization?

Today we’re going to talk about a basic, (but from time to time useful) feature of Java — serialization.
Let’s start with theory. So what is serialization?

To serialize an object means to convert its state to a byte stream so that the byte stream can be reverted back into a copy of the object

[Serializable Objects, Oracle Java Documentation]

OOP - how to do it right? - part 1

When I started my journey with Object Oriented Programming I quickly found out many tutorials and trainings, which showed how to use OOP structures in code. Unfortunately, most of them demonstrate only how to write your first own class, interface. How to create an object. All of this was about language “grammar”, about key words, the way how to create structures used in OOP, etc. Yet, somewhere authors lost the most important information to share - why we decide to do this instead of looking for other solutions? Why an interface contains nothing more than abstract methods? Why all of those are public? What for are those visibilities? And so on...

What diagrams can tell you

let’s talk about diagrams

I know that many of you may feel sick at the very thought of UML’s, but, whether you want or not, in certain moment of your career you will have to work with them and, what’s more frightening, there’s a chance that you will have to create them on our own.

Why so many programmers don’t like diagrams anyway? Well, I think it’s because of some kind of unwillingness towards something unknown, in this particular case – to the language which is unknown for us. Because that’s what UML really is, a language that isn’t understandable by all of us. It’s a language that not each of us “speaks”.
However, today I don’t want to write about this.

It happens in each language, sometimes we can know essence without deep investigation of details. We just know, that in each sentence there are less important words, as well as those words which matter most.
It’s exactly like with those sentences with word “but” inside. We all know that everything that stands before “but” is irrelevant and the real sense is just after :) And that’s what I want to describe today: cases, when you don’t have to look deeper to understand the context. A quick look at a diagram is enough to get the hang of what is the most important in it.

Overriding - let's check how it works

what is method overriding?

Method overriding is a concept based on polymorphism which allows us to create a method with the same signature as in parent class to extend or change its behaviour. Let’s take a look at the definition:

Method overriding - allows a subclass or child class to provide a specific implementation of a method that is already provided by one of its superclasses or parent classes. The implementation in the subclass overrides the implementation in the superclass by providing a method that has same name, same parameters or signature, and same return type as the method in the parent class.

[Wikipedia - Method overriding]

Today we will check what is possible to override and what's not. I will also try to explain why it is so.

Take a look at Local Classes

what will it be about?

Recently I tried to explain what nested classes are and what you can do with them. There were a few words about Static Nested Classes and Inner Classes. I've also mentioned that there are two more types, which are special kind of Inner Class. And today I want to write something about one of it - Local Classes.

Ok, that's all great, but what Local Class is?

Local classes - classes that are defined in a block, which is a group of zero or more statements between balanced braces.

[Oracle Documentation - Local Classes]

Which means that you can define a Local Classes inside any block.
For example you can define a Local Class in a method body, a for loop, or an if clause.