It is rare but probably happens once in a few years that we write a very long list of if-else blocks. Not only this kind of code is hard to manage, it is bad for a single responsibility. And it’s slow. I just devised a faster and cleaner way to do it.
There has always been confusion and debates on what to do with “exception” and how to use it. Now, if you see “exception handling” in context of just a programming practice, or java, or a convention, you are sure to get challenged by both your team members and yourself. During my early years, I have been in turmoil for making right decisions on it. But over the time, I have learned lessons and found the real purpose of exceptions which I am gonna share today:
In the beginning, I had a hundred problems creating beans, and spent hours to understand how spring works. I produce a lot of modules and libraries and separate everything by features. So, my applications don’t have a simple model-view-controller folder-set as I have hundreds or even thousands of classes in enterprise solutions. And, I was facing issues with setting up my libraries which were not in the application package in spring. By application package I mean where the Spring Application class resides in and all the sub-packages.
So, what happens when packages are outside? – the beans are not created, the spring annotations do not work! The solution is pretty easy but hard to find unless you are already familiar with “spring keywords“. But, the only way to get familiar with spring terminology is to become a master of it first! Anyway, so my goal here is to write tutorials which would be easy to find with common keywords like “my beans are not working in spring”.
Let’s say we want to add a full-text search engine to you application. Apache solr is a open source and popular choice for search engines. Now, I am going to share a simple architecture to synchronize data between the primary data-store (like mysql, mongodb, etc) and solr engine.
I created an Android app for World Health Organization long ago. I made different kinds of search engines before with full-text indexing. This time I wanted to do something different. I had only 4 days to make the app. They had different kinds of contents like
- Plain text files
- PDF files
And they needed a search engine to search all the contents and show a unified result set ( Showing results in a same page with relevancy ). Now I could implement it in SQLite, but that would mean a lot of task and the gain would be much lesser than a document-based search engine like Apache Lucene.
As I built many applications before, when I started building with springboot, following the springboot books is not enough for my architectural needs. So, I ran into many critical problems by going beyond those books. I will write them up to help beginners in spring ecosystem like me.
I started writing my first spring and the first springboot application today. The project requires mongodb and mysql as databases. My application’s domain objects are highly hierarchical and we need to make different kinds of search engines for many child classes. So, there needs to be some violations from common patterns like “field shadowing”. Though it’s only for the purpose of data and search layer, it doesn’t affect the object model of the application. So, I needed to change field behavior in subclasses which are different entities or collections in Mongo store. Basically I needed to put a annotation on subclass to enable an index on a field.
Handling null can be problematic in code organization and management. So, there are two very common patterns used by experienced developers now and then. One is “Null object pattern”, where you return an object which states a missing object, and another is “Special Case Pattern”. This article is to “How you can write effective objects for those patterns and why you should use them instead of returning null or throwing exceptions”
I read through many discussions related to Singleton Patterns, and different developers dislike it for different reasons. Not all the reasons make a pattern evil, because many of those reasons doesn’t really make your software really bad. I will be writing here each of the reason, and try to explain whether the reason is justified to call Singleton Evil:
I would enlist here the list of articles which explains why DI is important in designing software today satisfying a few goals like
- Code management
- System learning curve / Ambiguity Management
- API Dependency management
- Application Life Cycle