![]() In object-oriented (OO) languages, modules are classes (e.g. Reading this definition, a couple of questions come to mind:Ī module is a mid-level programming construct, combining functions with data structures. The Single Responsibility Principle states thatĮach module should only have a single reason to change. The S in SOLID represents the Single Responsibility Principle (SRP). SOLID is an acronym, made up from the initial letters of the five principles that compose it. You almost have to write a big ball of mud, understand how it works, then redesign it as several different components, each taking responsibility for a part of the whole.We are continuing from yesterday’s article on the purpose of the SOLID Principles. I would say that, as a new developer, it is VERY HARD to break everything down to this level. The move also drastically reduced each class' code base and made them MUCH easier to test. This allowed for different types of producers to be created, all of which could be treated exactly the same, even though they did vastly different things. Components in the system would then pass these producers around, combine them with others (the responsibility of the producers), and eventually use them to produce Y. For those parts of the system that needed to be flexible, rather than pass collections of X class that are used to produce Y objects, a class was created to encapsulate the process of production of Y objects. SRP was even taken down into the arguments and return values of the class methods. If you wanted to change one part, you didn't override a method, you would produce another object that extended the requisite interface/base class and performed its job differently. Each one was composed of different objects which performed key functions of the overall process. You'd have your interface, a base class and, possibly, one or more implementation classes. ![]() So we redesigned everything along SRP lines. It was obvious this design would cause the framework to be very rigid and inflexible. This also resulted in massive classes that required tens of unit tests to get the code coverage over 80%, and the complexity was such that you weren't sure if you covered everything correctly. This also resulted in unexpected dependencies-an abstract method taking a collection of class X to produce object Y defined in a base class dictated that EVERYBODY had to do it this way, even when it made no sense for half of the inheritance tree. The methods were all virtual and didn't change the object's state, so it was pretty easy to do this.īut as the system grew, it became more clear that the framework was going to end up with a series of monolithic objects, each with looooong inheritance chains. ![]() In order to change those behaviors, you had to extend those classes. ![]() I'm working on a project that does lots of different, horribly complex things, in a framework that is supposed to be easily extensible by others.Īt first, classes were large and did multiple things. If you need to deliver something then go ahead and do it fast and dirty. I do agree with them that like anything you have to be pragmatic about these things. I've found that the investment of keeping the quality of code as high as possible has always paid itself back within a few months. The customer does care about having new features implemented quickly and that's where code quality comes in. And he's right, the customer doesn't care. He doesnt see code quality as a great benefit for the customer. Jeff also missed the point on code quality. So the 20% extra code i have to maintain pays for itself. I hardly ever have situations where changes in one part of my application break other parts. If I look at what I do I write 10 maybe 20% more code (usually interface definitions) but because everything is highly decoupled it's far more maintainable. The main argument against is as usually "you write more code". I also heard the podcast and it sounds like neither Jeff nor Joel has tried any of the things they're talking about long enough to really asses the benefits. I have had some experience applying SOLID principles and my experience has been mainly good.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |