@Autowired and optional dependencies

@Autowired annotation makes our lives easier. It also can result in decreased amount of code if we are using it on properties of the class. We need neither constructors nor setter methods. It looks great at first glance, but the benefits rarely come without cost.

Today I want to make you aware of the costs that have to be paid.

Constructor or setter?

It goes without saying that every object needs to be created before it can be used. It does not matter whether we are talking about a domain, frameworks, libraries or any other type of the classes. When your code is an Object-Oriented, those classes are only definitions of the objects. You cannot use objects before they are created.

When we are talking about object’s initialization, we often need to think about dependencies. How will you inject them? Will you use the constructor or setter?

Abstract Factory or Factory Method?

Today I would like to tell you about Factory Method Pattern and Abstract Factory Pattern. The purpose of the article is to help you recognize places where one of them should be used.

Tell, don't ask

about rules and principles

Some time ago I wrote about the Law of Demeter, about the advantages of following this law. Today I would like to write about the “Tell, don’t ask” principle. The principle that is, at least in my opinion, the starting point for the mentioned law. Following LoD is one of the consequences of applying the TDA principle.

Ok, but what should we tell and what shouldn’t we ask about anyway?

OOP: How to do it right. What the method is?

Some time ago I wrote about objects' attributes. Parts that identify them. However, the objects are exactly like us - it’s our behavior that determines who we are, makes us who we are. This behavior and reactions are the things that really interest others. Would Sebastian be the same annoying person if his name were different? Assuming there's no magical power in our names he probably would.

Don't get me wrong, I don't want to minimise the importance of object's attributes. The behavior of the object often depends on them, e.g. if the age is one of person’s attributes, it's clear that it determines many activities that the person can or cannot do.

Do you really want to test it?

I’m probably not the only one who had a chance to participate in deliberations over whether some private method should be tested (because it’s worth it) or not (because we shouldn’t test private methods). I’m not writing about pure theoretic conversations while you’re filling your cup of coffee and talking with your colleagues. I believe that in those moments most of developers would tell you a firm NO.

But what about situations when you are working with real code? When all those rules and principles are not so strictly followed? Would they also say NO so firmly? Based on my experience, I can tell you they wouldn’t. At least not always.

Ok, but should they? Should we? Or is it yet another nice-to-follow rule the observance of which depends on context?

OOP – how to do it right? – attributes

primitive types and objects

The values of attributes of particular objects are the things that allow us to recognize a specific object to determine whether two objects are different or similar. It lets us identify instances of the class.

We can categorize attributes into two types:

• Primitive types: byte, short, int, long, float, double, boolean and char.
• Objects – they’re implemented as an aggregation - association or composition.

Attributes which types are primitives are the one which are directly related to the instance of an object. On the other hand, aggregations define an object’s relations.

We distinguish the following types of aggregations:

• Association – the object which is a part can exist on its own, even when it’s not a part of relation.
• Composition – the object which is a part that cannot exist without main object. It cannot be shared with any other object. If the main object is removed, then all its compositions as well.

To give you an example, I will use domain that is well known to all of us – software development.

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.

Enums - what can go wrong?

In last two posts I showed you what enums in java can give us and what we can do with them. I hope that right now you will agree with me that enums are really powerful.

Today I want to present you a few things which you can treat as a warning sign whenever you will see something like this in your own code.
But you need to remember that it's just a sign, nothing more. It doesn't mean that you shouldn't solve your problems in presented ways, it would be enough to take a deep breath, look at code once again and then made decision if it should be changed or not.

On the end of my last post I asked a couple of questions about examples given by me. If there was something worrying in them? Were they good or not?
Today I will try to explain why I asked those questions and I will share with you my thoughts about problems that can occur when we are overusing enumerations.

Let's start :)