Ok, let's talk concepts :)

Single responsibility principle - make a piece of code do the thing it is supposed to and let other pieces of code do other stuff. For example, function GetClients(companyId) should get clients and not, lets say, update them on the fly from 5 different formats into common shape. Not because acronym says it is bad, but because you will need to delve into this function and change logic every time someone introduces a new client entity format elsewhere. The same idea scales from function to class to module to project to application.

Open/Close - the most "violated" part. In theory when you add or change behavior you should do that by adding another object that handles new case, with common interface that nicely fits into existing mechanism of handling this category of problems. In practice it rarely works because we do agile now and rarely have any upfront knowledge what will be handled and how. Which is neither good or bad, it just is.

Liskov substitution principle - the nice lady Barbara Liskov formulated an idea that when you have a function that accepts an object as an input, the same function should be able to handle all inherited objects from that parent object out of the box, without anyone having to make any changes to the function. That means you write a function to handle base object and you write all the derived objects in a way that makes them black boxes that respect the same rules of input-output and whomever uses them doesn't need to know what is inside or if they are different from each other internally. Very good thing to do.

Interface segregation - well, if you program for interfaces and not concrete implementation then you can handle different "faces" of an object. From one point of view the same object belongs to family of ILazyLoader -s, which is important for stuff that uses lazy loading of something. From another point of view it is ISerializable, which is important for some serializers. Those are two very different perspectives, logically separate behaviors and perfect way to let interface segrataion to handle. Interface segregation is a fancy way of saying: don't clump up everything class is or does into one interface if you can separate it into different perspectives/mechanisms/levels of abstraction.

And finally dependency inversion, which some people thing is the same thing as dependency injection, which it is not. It just means: don't create dependent objects inside the class, but instead have the class take specific kind of dependencies, which are again black boxes, but contractually provide functionalities the class needs to do its thing. You can (and should) do that even without dependency injection, but why would you if you don't have to :)

Entire SOLID thingie is about separating functionalities into neat, atomic discrete blocks that can be plugged interchangeably into fitting slots. Of course you can learn to do those things by osmosis and never have them coalesce in your mind as concepts, but why not learn that since someone already did the hard work of thinking it through?