Table of Contents
If you google “Software Design Principles”, there are a lot of them. They all come back to one idea: the localization of reasoning. The differences are that they arise in various problematic situations, and call for different design remedies. It all points to one principle, which is that changes should be ideally localized to one place, and that each place should correspond to one kind of change. If the class is aligned with one change, it is aligned with one behaviour or responsibility within the system.
We start with a change we want to make within our code. If the change is too difficult to make, for some reason or another, the change reveals a problematic lack of abstraction, also known as a code smell. We then discover what makes our code problematic and refactor our code to arrive at more principled code.
Principled code doesn’t start out that way. We look realistically at what we are trying to enable programmers to do with our code, what kind of change they want to make, and then emerge principled code through refactoring. 
What is the Law Of Demeter?
Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
SOLID is a nice combination of principles to remember because they give a good coverage of likely problems that a programmer can encounter, and from there you can better understand other design principles.
Information hiding is one of the most important design principles, one that has been around for a very long time. The idea is that the programmer makes decisions to hides certain implementations from the rest of the program. The main task is to decide which features should be hidden.
You should only expose necessary functions, and use abstraction to hide complexity. For example, the caller to a function should not have to assume anything about how the interface is implemented. The effects of internal changes should be localized, and by separating the design decisions that are likely to change, you protect other parts of the program from many modifications if the design is changed.
To gain more experience with object oriented design principles, I recommend practicing recognizing code smells within your own code and thinking about how changes to your designs could violate any of the above principles. Once you have a solid grasp of SOLID, you will find that other coding principles are also based around this idea of localized changes and abstraction.