💃 Learn these rock SOLID principles 🕺

Good morning, Salesforce Nerds! Have you ever worked with a rock star developer 🤘 that seemed to be able to crush everything sent their way? They're able to work fast to turn out features that scale and the team can maintain or extend easily? How do they do it? It's not magic! 🪄 Let's take a look at how senior engineers think when they think about code! 👷 Today, we cover the SOLID principles!

Some of these can be confusing! If you have any questions hit us up - we love this nerdy 💩!

Agenda for today includes

• Foundations

• SOLID Principles

• Daily Principle

• All the Memes

Foundations

Inside the world of software engineering, SOLID is an acronym for five design principles that aim to enable developers to write code that is scalable, maintainable, reusable, extensible, and testable. That's pretty much all of the critical ABLE's! 😂 

These principles are not new - they were first introduced by Robert Martin (aka Uncle Bob) more than 20 years ago. These principles are still relevant today and (in my humble 💃 ChaCha 🕺 opinion) are critical for successful enterprise level implementations.

SOLID Principles

☑️ Single Responsibility Principle

This principle states that a class should only do one thing and therefore it should have only a single reason to change.

What we're saying here is simply this: 🛑Stop putting so much stuff into one class! Think about what the class should be doing and make it do that thing really, really well.

Think about it like this for a second. Your app has to include functionality to query Account data, wouldn't you be much better off having a single class be responsible for executing these queries and returning data to callers instead of peppering in-line SOQL statements everywhere? This class will now be solely responsible for getting your Account data across the entire codebase! Other classes loading Account data can off-load this responsibility here. 🔥

☑️ Open-Closed Principle

This principle says classes should be open for extension and closed to modification.

Effectively, what this principle means is - we want to write code in a manner that supports being able to add new functionality to a class without having to touch the existing code for the class. Why? Well, whenever we modify the existing code we are risking the introduction of bugs! 🪲 

Think about this from our Accounts querying perspective - our class is only responsible for querying Account data. 👍 Suppose this class contains a bunch of methods that each represent the selection criteria (WHERE clause) for different queries. If we go and change one of the existing methods to support a new feature, how that will impact the other places in the codebase that are already using that same method?

☑️ Liskov Substitution Principle

Named after the person that introduced the concept - Barbara Liskov - it states that subclasses should be substitutable for their base classes.

This is all about a programming concept known as inheritance. Here's a common example, suppose we have a class called Animal. Then we have three other classes called Dog, Cat, and finally Bird. With a simple declaration at the top of each class, a developer and specify that these inherit from or extend Animal - making Animal the base class and others a subclass. This is helpful because now we can define base functionality in the Animal class that the subclasses inherit themselves. For example, since all of the animals need to breath, eat, sleep, and 💩 we just define this stuff in the base class and it's all available to the subclasses!

What this principle is aiming to say is that subclasses should be 💯 interchangeable with their base class. In our scenario, if we added a method to the Animal class to support flying then we'd be breaking this rule because Dogs and Cats can't fly. It would only apply to the Bird class. Well, maybe cat's can defy gravity a little bit 😂😂

☑️ Interface Segregation Principle

This principle requires that a client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.

Say what?? 🤔 Okay, so an Interface can be defined as a "set of abstractions that an implementing class must follow".

In other words, we create an interface by defining the method signatures (the name + parameters + type of data being returned). These are the "set of abstractions". Then we create any number of classes that implement this interface - enforcing the classes to include the method(s) defined in the interface - these are the "concrete classes".

Now, segregation means keeping things separated, and this principle is about separating our interfaces - opting for many specific interfaces rather than one general-purpose interface.

Let's think back to our class that's responsible for querying Account data. If we follow this pattern for other SObjects (and we should be) we will probably have another class to query Opportunity data. This principle basically says that each of these classes should be implementing their own interface instead of sharing one. This will help us avoid implementing unnecessary methods. You might be querying for Opportunities by their Stage, but this wouldn't apply to Accounts. ⛔

☑️ Dependency Inversion Principle

My personal favorite! 😍 This principle states that our classes should depend upon interfaces or abstract classes instead of concrete classes.

If you're still reading then congrats! 🎉 We're almost there! And this one's a great one to end on! Dependency inversion is arguably the most important principle to remember when building software. But, don't let the big words freak you out - this is essentially saying that systems built with "inverted dependencies" are ideal because of their loosely-coupled design.

What's an inverted dependency? Well, when a class knows about the details of another class, it raises the risk that if we make any changes to one class that will break the other class. So, we must keep these high-level and low-level classes loosely coupled as much as possible. To do that, we can make both of them dependent on interfaces instead of knowing all the details about each other. When you do this, you invert the dependencies.

So, takeaway here - use interfaces! 💥

Daily Principle

and now....Your Daily Memes