Dave - Big guy, beard, likes software development

The "I" in SOLID stands for Interface Segregation Principle. It's more of a mouthful to say than it is to understand. It states : Clients should not be forced to depend upon interfaces that they do not use. Succinct right? i.e. Keep your interfaces as small and modular as possible. It maximizes their potential for reuse and prevents clients/end users from depending upon functions/methods they don’t really need.

The "L" in SOLID stands for the Liskov Substitution Principle. In my opinion, this has the most complicated definition, but the most obvious implementation, you're probably doing this without thinking about it. This principle is named after Barbara Liskov, who  defined it in 1988 as : What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behaviour of P is unchanged when o1 is substituted for o2 then S is a subtype of T. Eh? Robert Martin defines it as : Derived classes must be substitutable for their base classes. In my mind, this is one of the most fundamental principles of Object Oriented Programming? Definitely a staple when learning Java at University (I certainly remember this. "Dog and Cat are both types of Animal …"). Dependency injection frameworks put this into practise by supplyin

The "O" in SOLID stands for the Open-Closed Principle. This states : You should be able to extend a class’s behaviour, without modifying it. If your class/unit of code is simple and keeping to the Single Responsibility Principle, it should be easy to reuse it and create a new class/unit of code to add the new behaviour required. A little like the if this then that flow of working. Simple.

The "S" in SOLID stands for Single Responsibility Principle, and it’s probably the principle that gets the most bad press. It states that each class should have just one responsibility. My take on this is that this principle is another way of saying Keep It Simple Stupid (KISS). To quote Robert Martin himself : A class should have one, and only one, reason to change. One of Uncle Bob's favourite examples is "an “Employee” class that calculates the pay and saves the employee data to a persistence store. If there's a change required in how pay is calculated, the class will have to be changed. If the DBA makes some changes to the database schema, the class will probably have to change as well." Here the "Employee" class has two responsibilities which violates the SRP. One is business logic related and the other data infrastructure related. According to the Single Responsibility Principle, these concerns shouldn’t reside in th

One of my favourite set of principles as a developer has always been the SOILD principles. I believe they promote well thought out code, and that if you aim for those principles, no matter where you end up, it's usually a pleasant place. I wanted to take a look at how SOLID fits in the 2020 landscape of cloud, serverless, containers etc and see if the lessons these principles teach us are still relevant in today's world. S:  Single Responsibility Principle O : Open-ClosedPrinciple L: Liskov Substitution Principle I: Interface Segregation Principle D: Dependency Inversion Principle I would argue that these principles are as relevant today as they've always been. The benefits of employing the Single Responsibility Principle in Lambda API endpoints on AWS, for example, are the same as in classes or objects. In my experience, the simpler the code, the easier it is reason with, deploy and ultimately, maintain. That’s not to say that you should beat yoursel

React Fragments Key Error If you get the following error: Each child in a list should have a unique "key" prop when you're using React and React Fragments, add the key prop to the react fragment. Example < React.Fragment   key = { i } > <!-- Some stuff here --> </ React.Fragment > #ProblemSolved