I think that every sane developer agrees that the SOLID principles are good and useful and when the time comes, you should apply them... but in this blog post I will concentrate on the: when the time comes part. I will probably get a lot of hate for writing this blog post, probably some people … Continue reading SOLID premature optimizations
This principle states that: A class should have one and only one reason to change, meaning that a class should have only one job. A classic example is the one with the shapes. Let's see it: In the code above we have a problem with the getArea() method. The problem is that it handles the … Continue reading Single-responsibility Principle
Many developers try to improve their programming practices by learning the SOLID principles. No harm here, this is a very good thing, the only problem is that without some experience (I mean a lot of it), you can easily make your code utterly complicated using the same principles that were designed to make your code … Continue reading SOLID principles can go wrong
