Кажется, у нас есть еще один претендент на звание "лучший повод развести холивар".
До этого с этим отлично справлялись несколько известных аббревиатур. Озвучив который, можно было смачно так разочароваться в любом человеке.
И мне кажется, что причина этого лежит в возможности по-разному трактовать то или иное понятие.
Сейчас я изучаю, как подходы к архитектуре ПО менялись с течением времени. В связи с этим читаю много статей и литературы.
И от одного источника к другому, я замечаю, как одно и то же понятие несет в себе так много смыслов, что его использование автоматически вводит в сильное замешательство.
Инкапсуляция. Давайте просто посмотрим на определения:
🔹 Русскоязычная википедия.
процесс разделения элементов абстракций, определяющих её структуру (данные) и поведение (методы)
🔷 Англоязычная википедия.
объединение объекта и его метода с данными
🔹 Другой ресурс, тоже вики, специализирующийся на разработке ПО.
процесс объединения элементов для создания нового объекта
При том в научных статьях, книгах и блогах известных специалистов сохраняется точно такая же путаница:
🔸 Статья на которую ссылаются другие 23 статьи в которой:
инкапсуляция используется для создания абстрактных типов данных, которые можно изменять только через их внешний интерфейс.
🔸 Мартин Фаулер
Это говорит о том, что поля объекта не должны быть общедоступными, вместо этого весь доступ извне объекта должен осуществляться через методы доступа.
🔸 Bertrand Meyer в книге Object-Oriented Software Construction вообще говорит что это синоним Information Hiding
Не обязательно ходить по всем перечисленным источникам. Я лишь хочу подсветить проблему:
🔻У нас НЕТ нормального/единого определения такого базового термина как инкапсуляция!
Т.е. при работе в команде, упоминая данный термин, вы должны держать в голове ворох расплывчатых определений, чтобы понять, что имеет в виду другой человек. Точно так же с чтением книг и статей.
Многие авторы, при этом, не чураются надумать себе какое-то 3 определение и найти тайный смысл.
Изучая, пробираясь через весь этот ворох, для себя я сделал пару выводы:
1️⃣ Каждый раз при упоминании данного термина, желательно уточнить у другого человека, что он имеет в виду.
2️⃣ Каждый раз, видя это термин в книге/статье, подбирать подходящее определение и пытаться понять, что хотел сказать автор 🤬
3️⃣ Я перестану употреблять этот термин. Чтобы не вводить никого в заблуждение.
Вместо него просто буду использовать синонимы, которые отлично отражают суть:
🔸 Модификаторы доступа, интерфейс, абстракция: в случае если хочу сказать про сокрытие/ограничение доступа
🔸 Представление объекта в памяти, виртуальная таблица, объединение методов и данных: для случаев, когда захочу описать особенности ОО языка
Ну и если я могу дать рекомендацию:
🔻 Держите в голове суть беседы, обсуждения, разговора, а не корректность терминов, когда говорите о разработке.
Как по мне, это отличный показатель того, на сколько большой путь еще предстоит проделать разработке как инженерной дисциплине.
Что супер! У всех нас есть еще куча времени, чтобы вписать себя в историю 😜
Ставьте 👍 если заходит подобного рода контент!
#аббревиатуры@UniArchitect
