Thursday, March 24, 2016
Friday, March 18, 2016
The first exception changes the rules of the game
We are developers who care. On a daily basis we use techniques and practices that help us make our code easier to maintain, develop and understand. We carry out code reviews, pair programming, TDD, etc. We use tools that allow us to automate many things. We have rules that help us protect common coding standards and design practices. Rules that we agreed to follow. Rules that help us improve the quality of our code and its design.
Yet, there is a one challenging thing in following the rules. If you agreed to follow them, you should not allow for any exception. Why? Because the first exception is the first step for more exceptions. The more exceptions are made, the less valuable the rule becomes.
Yet, there is a one challenging thing in following the rules. If you agreed to follow them, you should not allow for any exception. Why? Because the first exception is the first step for more exceptions. The more exceptions are made, the less valuable the rule becomes.
Wednesday, March 16, 2016
@Autowired all the things!
Recently I have written that @Autowired annotation make our lives easier in that it allows us to write less code. However, using it may often make your design more complicated. Especially when we are talking about using it on class’s properties. It makes it easier to violate Single Responsibility Principle. It makes it easier not to notice that.
It is ok to use @Autowired with properties, yet, I think, that presence of the constructor visualizes the problem with too many dependencies when it occurs. Even without exercising additional care from our side.
It is ok to use @Autowired with properties, yet, I think, that presence of the constructor visualizes the problem with too many dependencies when it occurs. Even without exercising additional care from our side.
Monday, March 7, 2016
@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.
Today I want to make you aware of the costs that have to be paid.
Subscribe to:
Posts (Atom)