Инкапсуляция. Как сделать.

Я перечитала книгу "Эта странная жизнь" про ученого Любищева по ссылке Яны Франк. Ее поразило в нем то, что он записывал все, что делал за весь день в часах и минутах. А меня удивило, что для каждой книги(большой и умной) он писал конспект и критику. Я попробую тоже конспектировать книги по программированию, что я сейчас читаю. Не знаю, насколько меня хватит и насколько это будет полезно.

Итак, сейчас я читаю "Совершенный код" Макконнелла.

За сегодня я читала главы по инкапсуляции из раздела "Качественные интерфейсы классов".

"Без инкапсуляции абстракция обычно разрушается" - эта цитата определяет главный принцип сокрытия данных. Инкапсуляция - один из принципов управления сложностью проекта. 

Автор предлагает несколько принципов, позволяющих добиться сокрытия методов и данных классов.

1.  Минимизировать доступность классов и их членов.
2.  Не предоставлять прямой доступ к данным-членам, а только к методам доступа к данным - с этим пунктом связано у меня больше всего ляпов в моих бывших и настоящих программах. В классах, занимающихся расчетами, обычно очень много данных, которые являются результатом работы. Например, в программе "Mittens". Делать к ним методы доступа я поленилась. А по данному принципу это было необходимо. Хотя, я до сих пор не хорошо понимаю, как можно программы расчетов чего-либо сделать полностью ОО. Мне кажется, не зря до сих пор большинство расчетов остались на фортране. 
3.  Не включать в интерфейс класса детали реализации. В книге есть интересный пример для С++, как скрыть реализацию в заголовочном файле.class A{public:    Aresult Funk() const; ...private:    AEmplementation *a_emplementation;}В классе  AEmplementation находится тот код, который не должен быть доступен классу, использующему класс А.
4. Не делайте предположений о том, как класс будут использовать его клиенты. Все, что нужно, должно быть видно из интерфейса. Если какие-то значения нельзя указывать, то проверку значений не нужно отдавать классам клиентам.
5.  Избегайте использования дружественных классов. Я уже не помню точно, как их делают, т.к. ими не пользовалась. Автор указывает шаблон State(Состояние), как дисциплинированное использование таких классов. Шаблон не знаю. Нужно будет посмотреть потом.
6. Не делать метод открытым только потому, что он использует открытые методы, посмотреть, укладывается ли он в абстракцию этого класса.
7. Ценить легкость чтения кода выше, чем легкость его написания. Золотые слова! Можно их писать на мониторе, когда лениво печатать. 
8. Очень осторожно относится к семантическим (смысловым) нарушениям инкапсуляции. 
9. Остерегаться слишком жесткого сопряжения. 

Итак, итог.

• Минимизировать доступность классов и их членов.
• Избегать дружественных классов
• Делать данные базового класса закрытыми, а не защищенными, чтобы наследники были меньше сопряжены с базовым.
• не включать данные-члены в открытый интерфейс класса.
• остерегаться семантических нарушений инкапсуляции.
• соблюдать "правило деметры" - А знает о Б, но не знает о том, какие методы Б вызывает.

 Самой главный вывод автора - нужно программировать "через интерфейс" - т.е. использовать класс так, как будто кроме его открытых членов больше о нем ничего не известно. Это приводит к низкому сопряжению, хорошей абстракции и понятному коду.