Skip to main content

Posts

Ruling the code with Rules Design Pattern

Greetings! As a big fan of Chain Of Responsibility design pattern I was thinking to move out the if condition into a separate method so that I can loop through chain externally. It turned out that I end up implementing Rules Design Pattern. I first encountered the pattern few years ago in a C# article ( https://www.michael-whelan.net/rules-design-pattern/ ). You can find the pattern in this course patterns-library . Rules Design Pattern In this pattern, we decouple the business rules from their processing by encapsulating them in to separate classes. We can add/remove rules without impacting the existing logic. This looks much like the Chain of Responsibility except processing rule is separated. One glitch I have faced is we are unable share one rules data with another as the rule and processing are decoupled. Anyway, it is worth to try. I'm not going re-invent an example. Instead i'll use the same example as in C# article but with minimum logic. public class Customer { pr

Let's Restore Agile

Greetings! I have been working in Agile environments for different companies for many years. We had/have a Scrum Master and Daily Standup, and that is it. That is Agile. This is what made me think "daily meetings are for bad managers". I started reading, practicing more on Agile and found this ( how-keep-your-team-from-getting-agile-wrong-hasitha-liyanage ) interesting article where I got more courage to apply Agile principles, values into my team. Where to Start? The first thing anyone should do is to read agile manifesto. It quite amusing that even certifed scrum masters/managers have no proper understanding on the manifesto. It Is Not About Processes The very first princile in Agile is "team over process". What does mean is, processes have value but the team has more value. For an example we don't need Daily meetings if the team decided so. It is the team decide how to work. Supoort and Trust Have you ever felt Trusted and Supported? If the answer is NO, you

Do not use magic in unit tests

Greetings! Working in legacy system is both fun and hard. It becomes harder due to lack of tests. Not only that, it is difficult to write tests due to the ways code is written. As our legacy system doesn't have a DI framework like Spring, we are maintaining object lifecycle manually. We have a policy to create singletons (I do not know why, I plan to remove them anyway) which made them harder for unit tests. The way to write unit tests for these classes is using reflection and mocking frameworks (scary isn't). Let's see a basic example of such a class. public final class AppointmentRepository { private AppointmentRepository() { } private static class LazyHolder { private static final AppointmentRepository INSTANCE = new AppointmentRepository(); } public static AppointmentRepository getInstance() { return LazyHolder.INSTANCE; } } public final class AppointmentService { private final AppointmentRepository appointmentRepository; private AppointmentS