- #Interface segregation principle full
- #Interface segregation principle software
- #Interface segregation principle code
#Interface segregation principle code
Simple code is both open and closed.Ī program that uses an interface must not be confused by an implementation of that interface. And we want to make sure that we don’t have to change the right code just to make the wrong code work again. Much of the existing code is still right. When requirements change only part of the existing code is wrong. Do we want to keep business rules isolated from the nasty little details of the GUI, and the micro-service communications protocols, and the arbitrary behaviors of the database? Of course we do!Īgain, Dan’s slide gets this completely wrong. Or… Do we want to separate abstract concepts from detailed concepts.
Can you imagine working in a system that did not have device independence, where writing to a disk file was fundamentally different than writing to a printer, or a screen, or a pipe? Do we want to see if statement scattered through our code to deal with all the little details? Of course we want to create modules that can be extended without modifying them.
#Interface segregation principle full
Of all the principles, the idea that anyone would question this one fills me full of dread for the future of our industry. The SRP is one of the ways we keep the code simple.Ī Module should be open for extension but closed for modification. (or that he was being ironic, which knowing Dan, is far more likely) His answer to the SRP is to “Write Simple Code”. You can create a tangled microservice, or a tangled set of microservices if you mix code that changes for different reasons.ĭan North’s slides completely miss the point on this, and convinces me that he did not understand the principle at all. We make sure that modules that change for different reasons do not have dependencies that tangle them. We keep code that is changed for different reasons separate so that changes to one part to not break other parts. We do not mix SQL queries with communications protocols. We do not mix business rules with GUI code. It is hard to imagine that this principle is not relevant in software. Separate things that change for different reasons. Gather together the things that change for the same reasons. SRP) The Single Responsibility Principle.
So let’s walk through the principles, one by one. Every new generation is wrong about that which is something that every new generation learns once the next new generation comes along to tell them how much everything has changed.
#Interface segregation principle software
Software is still if statements, while loops, and assignment statements - Sequence, Selection, and Iteration.Įvery new generation likes to think that their world is vastly different from the generation before. This is because software hasn’t changed all that much in all those years - and that is because software hasn’t change all that much since 1945 when Turing wrote the first lines of code for an electronic computer. The SOLID principles remain as relevant to day as they were in the 90s (and indeed before that). I wrote the following letter in response: I think we should consider Dan North’s position on SOLID – “Just write simple code.” The Liskov Substitution Principle is long out of date because we don’t focus on inheritance nearly as much as we did 20 years ago. His points were that the Open-Closed principle isn’t very important anymore because most of the code we write isn’t contained in large monoliths and making changes to small microservices is safe and easy. Lately, however, one of our managers, who doesn’t code much anymore, has questioned whether that is wise. Candidates were expected to have a good working knowledge of these principles. It went like this:įor years the knowledge of the SOLID principle has been a standard part of our recruiting procedure. Recently I received a letter from someone with a concern.
0 kommentar(er)
