What the reasons to use programming principals such as OOP, SOLID, etc.

Question

This post will discuss the purposes of using programming principals such as OOP, SOLID, etc.

Answer 1

The first compeling reason is that it is needed to provide a method to control the risks of making changes in modules. Developers have to be sure that changes in one module will not lead to uncontrolled failure in orher modules.

Therefore, the latter O from SOLID, meaning open for extension and closed for modification, is a way to implement this control.
How can we realise this O-principe? The easiest way is using an inheritance.
For example, we have the class Animal, and then we have recieved the requierment to extend this class by adding new feature. Animals have to have a method "making noise."

So, by taken into account all said above, there is a bad idea to add a new method into the class Animal. It can be dangerous and can provoke failers in other part of system. Instead of this it is better to create new class NoisyAnimal that will inherite from Animal.
Having done this, if class Animal was located in a separated class library (dll or jar), this library would not need to be rebuild.

Answer 2

Encapsulation is vitally important principle of OOP. While I was working with JavaScript libraries, especially in creating JavaScript library, I realised how important it is to understand this principle from the very beginning.

When I deployed my first JavaScript library all members of classes were public. I made them public just because there are no explicit ways to declare private members in JavaScript. However, of course not all of them have to be a public, most of them were created for implementation needs.

Users of this library saw these public members and used them in their own needs. In next version of library I changed implementation, in reason to optimize some methods, fix bugs, and so on, and I removed, in my view, all redundant members. So can you imagine the unhappiness of our users about the fact that they cannot use the next version of library without changing their code.
Moreover, of course they don't remember what members they used, so they realise it only after their tests had failed with new version of my library.

The statement to avoid using public members whose names are started with "_", cannot solve the problem due to the fact that in general the majority of developers don't care about future. They have to solve their problems right now, so if class members, whose names are started from "_", can help them to manage their problems, they definitely will use these members.

There should be the way how to avoid the possibility to use this helpers members. And encapsulation principle is exactly for this purposes. Make public only those members who are really required to be public.