Форум программистов, компьютерный форум, киберфорум
С++ для начинающих
Войти
Регистрация
Восстановить пароль
 
 
Рейтинг 4.89/18: Рейтинг темы: голосов - 18, средняя оценка - 4.89
4 / 4 / 0
Регистрация: 26.10.2015
Сообщений: 52
1

Четкое понимание определений

30.08.2019, 08:26. Показов 3444. Ответов 27
Метки нет (Все метки)

Добрый день. Учу ООП. Есть отрывок из конспекта, который я пытаюсь понять.
Кликните здесь для просмотра всего текста

Инкапсуляция поддерживает принцип черного ящика.
Это означает, что реализация всегда должна быть в закрытой части. Закрываем мы
её для подмены в любой момент. (Можем поменять реализацию на клиентский код).
Идея в том, что мы, как разработчики, можем в любой момент поменять реализацию и у
клиента ничего не сломается, т.к. клиент пользуется интерфейсом(публичной
частью).Интерфейсы не меняются, изменение интерфейса ломает клиента.

То, как это понимаю я:
Кликните здесь для просмотра всего текста
Есть к примеру библиотека STL. В данном случае я - клиент и хочу воспользоваться ею.
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
#include "stdafx.h"
#include <iostream>
#include <vector>
using namespace std;
 
int main (void)
{
 
vector <int> v{ 3,5,7,9 };
copy(v.begin(), v.end(), ostream_iterator<int>(cout, "_")); //Интерфейс - это сигнатура метода?
 
return 0;
};
То есть метод copy(...); - это интерфейс?
То, как copy(...); сделан - это меня не должно волновать. И, допустим разработчики библиотеки решили выпустить обновление именно для метода copy(...);, в котором они оптимизировали какие то действия. Сигнатура метода остается неизменной, а реализация была изменена . Меня должно волновать то, что делает сам метод. И принцип черного ящика заключается в том, что мне нет дела до того, как сделан(написан) метод copy(...); т.е абстракция от реализации.
Я так это все понимаю?

Заранее благодарен
0

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Лучшие ответы (1)
Programming
Эксперт
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
30.08.2019, 08:26
Ответы с готовыми решениями:

Смазаное и не четкое изображение в убунту Линукс
Здравствуйте не могу разобратся что с Изображением глаза болят от фукнкционала убунту я безума...

Как задать четкое позиционирование элементу?
Есть верстка: http://morda77.zg5.ru/ &lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.01...

Как задать четкое позиционирование элементу?
Есть верстка: http://morda77.zg5.ru/ &lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.01...

Как сделать четкое изображение на втором мониторе?
Система: Windows 10 Основной монитор с разрешением 4k Второй монитор с разрешением FullHD...

27
488 / 285 / 128
Регистрация: 30.10.2018
Сообщений: 1,309
30.08.2019, 08:48 2
Марафет, практически ты понимаешь все верно, но задача инкапсуляции еще состоит в том, что бы скрыть от тебя элемент (поля, методы...) которые категорически запрещено трогать, именно для этого придумали private, public, protected.

К примеру:
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class Monster
{
private:
    std::string name;
public:
    std::string name() const 
    {
        // такой себе геттер
        return name;
    }
 
    void setName(const std::string& name)
    {
        // такой себе сеттер
        this->name = name;
 
        UpdateMonstersName();
    }
};
Здесь видно что, передача именни только через метод, почему? Потому что программисту нужно отслеживать изменения имени, и к примеру обновить список имен монстров, а для этого ему нужно отдельный метод, в котором он сможет это проделать.

Добавлено через 4 минуты
Цитата Сообщение от Марафет Посмотреть сообщение
Идея в том, что мы, как разработчики, можем в любой момент поменять реализацию и у
клиента ничего не сломается, т.к. клиент пользуется интерфейсом
Может скажу дичь, но почти никогда такого не замечал, все стараються пометить свой интерфейс как deprecated или legacy (что в обоих случаях значит - устаревший, и в поздних версиях собираеться убраться), ведь более продвинутый программист, юзая библиотеку, может посмотреть ана его внутреннюю реализацию, а при её изменения ничего не будет об этом знать, по этому новые методы отличаються либо названиям
setName -> setMonsterName
или же изменяються параметры...
1
4 / 4 / 0
Регистрация: 26.10.2015
Сообщений: 52
30.08.2019, 10:16  [ТС] 3
Я вам благодарен. Спасибо за развернутый ответ
0
Комп_Оратор)
Эксперт по математике/физике
8719 / 4428 / 598
Регистрация: 04.12.2011
Сообщений: 13,270
Записей в блоге: 16
30.08.2019, 14:08 4
Тема скользкая, особенно учитывая, отсутствие стандартных определений как таковых.
Цитата Сообщение от Марафет Посмотреть сообщение
Учу ООП.
Цитата Сообщение от Марафет Посмотреть сообщение
Инкапсуляция поддерживает принцип черного ящика.
С точки зрения ООП инкапсуляция это группировка функций и их данных в переменной - программном объекте. В С++ вид объекта, это уровень типа. Пользовательские типы устроены на базе структур и называются классами.
В самом С++ исторически инкапсуляция определена как сокрытие. Ваше определение, это оттуда. Главной задачей сокрытия является снижение связности (количество зависимостей) в программе между её частями. Тут и сохранение инварианта и возможность изменения реализации без влияния на интерфейс.
ООП определение шире. Без его реализации невозможно обеспечить сокрытие так как оно реализовано в С++. Кроме того, группировка данных и методов сама по себе, это не всё. Очень важно то, что такая группировка дополняется возможностью вызова методов для объекта, через ссылку на объект. Это позволяет использовать принципиально новые для процедурной модульности способы ветвления. Начиная с перегрузки методов и заканчивая наследованием и обобщённым программированием, на тип объекта возлагается ответственность за конкретную ветвь алгоритма (конкретный вызов). Посмотрите по верхам про ADL (argument dependent lookup). Только не углубляйтесь пока.
Вообще, всё что касается типов (а инкапсуляция имеет отношение к пользовательским типам - классам), это вечная тема. На каждом уровне - свой пакет сведений.
2
2145 / 690 / 265
Регистрация: 10.02.2018
Сообщений: 1,622
30.08.2019, 14:56 5
Инкапсуляция - это один термин, интерфейс - это другой термин. Оба означают разные вещи. Ваш вопрос больше касается интерфейса. Я бы сказал, что понимание интерфейса у вас верное.
1
Комп_Оратор)
Эксперт по математике/физике
8719 / 4428 / 598
Регистрация: 04.12.2011
Сообщений: 13,270
Записей в блоге: 16
30.08.2019, 19:45 6
Цитата Сообщение от Ygg Посмотреть сообщение
Инкапсуляция - это один термин, интерфейс - это другой термин.
Нет определений. Б. Страуструп избегает термина "инкапсуляция" предпочитая управление доступом. Разные авторы пишут несколько по своему. Мне нравится Липман. Язык программирования С++ 5-е изд.: Москва, СП, Киев 2018., стр. 331, гл. 7 Классы :
Инкапсуляция обеспечивает разделение интерфейса и реализации класса. Инкапсулируемый класс скрывает свою реализацию от пользователей, которые могут использовать интерфейс, но не имеют доступ к реализации класса.
на стр. 393 дан список терминов (фактически определений). Этот список может быть предметом спора, но как мнения одного из авторитетнейших (и лучших с моей точки зрения) авторов, имеет право на жизнь.
Инкапсуляция (encapsulation). Разделение реализации и интерфейса. Инкапсуляция скрывает детали реализации типа. В языке С++ инкапсуляция предотвращает доступ к обычного пользователя класса к его закрытым членам.
Неудачная двусмысленность по поводу того кто к чьим членам не может доступиться, присутствует. Отрадно видеть, вместе с тем, констатацию специфичного для С++ определения термина "инкапсуляция".

сразу за инкапсуляцией:

Интерфейс (interface). Открытые (public) операции, поддерживаемые типом. Обычно, интерфейс не включает переменные, - члены.
В целом понятно о чём говорит автор. Слово "переменная" - сам не люблю, но по необходимости использую. Автор понимает, что имена функций - ссылки. А поскольку сокрытие делается на уровне имён, то данные имена он (коллективный автор ) решил отделить от имён - полей которые можно изменять. Но константы и ссылки это тоже не переменные. В целом, если не придираться, - нормальное определение.
Марафет, что касается чёрного и прозрачного ящиков, то это тара из другого цеха. Рекомендую прочесть Приложение A. Глоссарий Приёмы объектно-ориентированного проектирования Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес. Это три страницы. Данная книга является классикой жанра и имеет право на цитирование в любых собраниях и обсуждениях.
Например:
Инкапсуляция - результат сокрытия представления и реализации в объекте. Представление невидимо и недоступно извне. Получить доступ к представлению объекта и модифицировать его можно только с помощью операций.
Слабостью данного (хорошего, по своему) определения, является (на мой взгляд) привязка к операциям. Дело даже не в том, что друзья должны стать операциями объекта. Это вопрос определения, хотя, является логически проблемным вопросом. Хуже то, что некоторые данные внутреннего представления, могут быть недоступны из внешних операций, как бы они не определялись. Они могут изменяться в следствии работы закрытых методов и являться следствием изменения состояния. То есть, такие изменения могут являться следствием целого ряда событий и не иметь четко детерминированного действия в терминах операций. Интерфейс, представление, реализация - это обобщения за которыми лучше бы сокрыть детали данного определения. Операция это уже деталь. Это опять же имхо.
А вот про прозрачный ящик:
Прозрачный ящик как способ повторного использования - стиль повторного использования, основанный на наследовании классов. Подкласс повторно использует интерфейс и реализацию родительского класса, но может также иметь доступ к закрытым для других аспектам своего родителя.
Чёрный ящик замыкает перечень определений:
Чёрный ящик как способ повторного использования - стиль повторного использования, основанный на композиции объектов. Объекты-компоненты не раскрывают друг другу деталей своего внутреннего устройства и потому могут быть уподоблены чёрным ящикам.
Тут ещё много чего дано в определениях и это интересно, как взгляд группы мэтров.
2
Эксперт С++
8426 / 4099 / 894
Регистрация: 15.11.2014
Сообщений: 9,208
31.08.2019, 13:48 7
Цитата Сообщение от kitsoRik Посмотреть сообщение
но задача инкапсуляции еще состоит в том, что бы скрыть от тебя элемент (поля, методы...)
бред собачий.

открой любой хедер с шаблоно-классов.
ну и чего он от тебя скрывает то?

в который раз замечаю: люди путают понятия "сокрытие" и "инкапсулирование"

Добавлено через 1 минуту
Цитата Сообщение от kitsoRik Посмотреть сообщение
именно для этого придумали private, public, protected.
ничего не скрывают, Кэп!
лишь ограничивают доступ.

Добавлено через 3 минуты
Цитата Сообщение от Ygg Посмотреть сообщение
Ваш вопрос больше касается интерфейса. Я бы сказал, что понимание интерфейса у вас верное.
у него вопрос касается именно понимания термина "инкапсуляция".
и это понимание - верное.

а вот что ты подразумеваешь под словом "интерфейс" - это не вполне ясно.
2
488 / 285 / 128
Регистрация: 30.10.2018
Сообщений: 1,309
31.08.2019, 14:03 8
Цитата Сообщение от hoggy Посмотреть сообщение
бред собачий.
открой любой хедер с шаблоно-классов.
ну и чего он от тебя скрывает то?
в который раз замечаю: люди путают понятия "сокрытие" и "инкапсулирование"
скажи мне, если тебе в начале учебы программированию сказали бы что, инкапсуляция - это способ инкапсуляции данных, ты бы понял о чем идет речь? Нет конечно, ты бы сказал "бред собачий", ведь ты не сможешь найти описания слова "инкапсулирования". Конечно, прятать в хедере никто ничего от тебя не будет, приватная часть кода на то и приватная, что бы не давать программисту возможности пользоваться ею в своем коде, а лишь физический просмотр содержимого этого приватного кода.

Цитата Сообщение от hoggy Посмотреть сообщение
ничего не скрывают, Кэп!
лишь ограничивают доступ.
Конечно, не скрывают, но тот же интелисенс тебе не подскажет о приватных методах верно? Потому что на то они и приватные. Я понимаю что ты среди тех людей, которым нужно все в точности перевести как есть, но пойми, что бы человек понял, ему нужно информацию подавать в понятном ему виде, а потом он из этого вида сможет себе объяснить разницу между "сокрытием" и "инкапсулированием".
0
Комп_Оратор)
Эксперт по математике/физике
8719 / 4428 / 598
Регистрация: 04.12.2011
Сообщений: 13,270
Записей в блоге: 16
31.08.2019, 14:54 9
Марафет, как вы уже поняли, различие толкований касается не только столпов веры крестовой. Мученики и схизматики не отстают.
Приведу еще один интересный момент относительно
Цитата Сообщение от IGPIGP Посмотреть сообщение
Б. Страуструп избегает термина "инкапсуляция" предпочитая управление доступом.
Вот не новая, но какая есть, книга: Язык программирования С++. Специальное издание. изд. Binom publishers, Москва, 2002
стр. 271, гл. 10.2.2 Управление доступом.
На стр.272
"Ограничение доступа к структуре данных явно объявленным списком функций имеет несколько преимушеств."
*****
"Защита закрытых данных базируется на ограничении использования(!) имён членов класса"
Далее он (понимая что ни защиты ни ограничения доступа нет, а есть сокрытие) как бы извиняясь за выбранную терминологию пишет:
"Эту защиту можно обойти манипулированием с адресами и путём явного преобразования типа. Но это, конечно, уже жульничество. С++ защищает от случайного, а не умышленного нарушения правил."
А сокрытие при использовании открытых библиотек, это тоже не надёжно. Другое дело, когда файлы поставляются в виде объектных модулей, например. Но против лома (реверс инженера) нет приёма. Всё относительно. Кроме тупости. Тупость абсолютна и категорична. Обратите внимание. Для того, хотя бы, чтобы не обращать внимания.
1
Эксперт С++
8426 / 4099 / 894
Регистрация: 15.11.2014
Сообщений: 9,208
31.08.2019, 14:56 10
Цитата Сообщение от kitsoRik Посмотреть сообщение
скажи мне, если тебе в начале учебы программированию сказали бы что, инкапсуляция - это способ инкапсуляции данных, ты бы понял о чем идет речь?
когда я в книже прочитал:

"инкапсуляция – это характеристика компонента (модуля, библиотеки, класса, функции),
которая определяет степень изоляции деталей реализации от клиентского кода.
грамотно инкапсулированный компонент позволяет изменять детали реализации этого компонента
без оглядки на клиентский код,
а клиентам позволяет эксплуатировать компонент без необходимости понимать,
учитывать, и вообще знать о деталях реализации"

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

Цитата Сообщение от kitsoRik Посмотреть сообщение
Конечно, прятать в хедере никто ничего от тебя не будет
ну и нафига ты тогда говоришь о сокрытии?

ты понимаешь, что такое сокрытие?

вот что б тебе наглядно было:

C++
1
2
3
4
5
6
7
8
9
10
11
// инкапусляция
 
#include <windows.h>   // <--- зависимость от ОС
class happy
{
   HANDLE blablabla;     // <--- клиент видит детали реализации
   void doWorkOlolo();
public:
   happy(); 
   void work();
};
клиентский код изолирован от деталей реализации,
но он зависит от них.

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
// сокрытие 
 
// <--- нет платформо-специфических зависимостей 
 
class happy
{
  struct detail;        //<--- детали скрыты
  detail * m_pimpl;
  int  reserved[32]; // <--- резерв для обеспечения бинарной совместимости
public:
   happy(); 
   void work();
};
клиентский код не просто изолирован от деталей реализации,
он вообще никак от них не зависит.

сокрытие используется для обеспечения бинарной совместимости
новых версий библиотек.

Цитата Сообщение от kitsoRik Посмотреть сообщение
Конечно, не скрывают, но тот же интелисенс
если ты понимаешь, что конечно не скрывают, зачем изначально писал:
Цитата Сообщение от kitsoRik Посмотреть сообщение
что бы скрыть от тебя элемент
и казалось бы: при чем тут интеллесенс?
Цитата Сообщение от kitsoRik Посмотреть сообщение
ему нужно информацию подавать в понятном ему виде, а
не в искаженном.

допущения допустимы, если они не перевирают факты.
2
3412 / 2771 / 751
Регистрация: 25.03.2012
Сообщений: 10,073
Записей в блоге: 1
31.08.2019, 15:12 11
hoggy, какая же ты зануда... когда я изучал классы мне было абсолютно по барабану на все эти разработки разработчиков и пользователей всё что я писал на практике это различные алгоритмы сортировки и всевозможные змейки, тетрисы, гоночки, танчики.
Не путай академические термины с тем, что надо реально начинающему программисту-любителю, не целющемуся в профессионалы.
0
488 / 285 / 128
Регистрация: 30.10.2018
Сообщений: 1,309
31.08.2019, 15:22 12
Цитата Сообщение от hoggy Посмотреть сообщение
и казалось бы: при чем тут интеллесенс?
при том, что он же не говорит тебе, "о слушай, тут есть приватный метод, я тебе его покажу, но ты его не можешь использовать", а наоборот, он от тебя "скрывает" эти методы, вот почему я писал "скрывает", какая нафиг разница "скривает" или "ограничивают", если в результате, программист который пишет код не получит информации об приватном методе.

А что значит "детали скрыты", мы что не можем увидить структуру деталей?
0
Комп_Оратор)
Эксперт по математике/физике
8719 / 4428 / 598
Регистрация: 04.12.2011
Сообщений: 13,270
Записей в блоге: 16
31.08.2019, 15:56 13
Цитата Сообщение от kitsoRik Посмотреть сообщение
какая нафиг разница
kitsoRik, вопрос темы состоит в правильном понимании определений.
А как хватились ан и нету их
определений, в смысле. Есть много разных, а значит - нету ни одного. С практической точки зрения, - бубен с надписью "Слава Ктулху" это всё что нужно. Знание умножает скорбь и съедает кучу времени.
1
4 / 4 / 0
Регистрация: 26.10.2015
Сообщений: 52
31.08.2019, 17:02  [ТС] 14
Цитата Сообщение от hoggy Посмотреть сообщение
разработчики библиотек могут свободно править свои библиотеки не боясь,
что изменения что-то поломают в уже написанном коде клиентов.
Все таки правильно я понял об инкапсуляции
Цитата Сообщение от Kuzia domovenok Посмотреть сообщение
начинающему программисту-любителю, не целющемуся в профессионалы
Я вообще то в свои 28 лет и пошел учиться в ВУЗ, причем на стационар, что бы сменить профессию и понимать различия между между такими тонкостями хорошо, дотошно изучая предмет.
Цитата Сообщение от IGPIGP Посмотреть сообщение
вопрос темы состоит в правильном понимании определений.
Именно за этим я и пришел на форум, что бы получить альтернативные точки зрения и на их базе сформулировать собственную
Цитата Сообщение от IGPIGP Посмотреть сообщение
Знание умножает скорбь и съедает кучу времени.
В точку сказано
1
2145 / 690 / 265
Регистрация: 10.02.2018
Сообщений: 1,622
31.08.2019, 17:12 15
Лучший ответ Сообщение было отмечено Марафет как решение

Решение

Цитата Сообщение от hoggy Посмотреть сообщение
у него вопрос касается именно понимания термина "инкапсуляция".
и это понимание - верное.
а вот что ты подразумеваешь под словом "интерфейс" - это не вполне ясно.
Возможно я не прав. Но в моём понимании инкапсуляция - это, в первую очередь, объединение данных и функций для работы с ними в единую сущность. Применительно к c++ - это суть классов. Сокрытие данных не есть инкапсуляция, а лишь дополнительная фишка сопутствующая инкапсуляции. Интерфейс в данном случае - это API для доступа к чему-либо. Сохранение работоспособности исходного кода без дополнительных правок при замене реализации отдельного модуля достигается сохранением API данного модуля. Весь пример автора топика сконцентрирован именно на этом. Так что я считаю, что тут в большей степени раскрыта суть интерфейса, нежели инкапсуляции.
1
Комп_Оратор)
Эксперт по математике/физике
8719 / 4428 / 598
Регистрация: 04.12.2011
Сообщений: 13,270
Записей в блоге: 16
31.08.2019, 17:31 16
Цитата Сообщение от Ygg Посмотреть сообщение
Возможно я не прав. Но в моём понимании инкапсуляция - это, в первую очередь, объединение данных и функций для работы с ними в единую сущность.
Я не могу сказать об очереди, но существует 2 термина "инкапсуляция". Вы говорите о том, что под этим понимается в современном ООП. То, что под этим понималось когда-то в ООП и то, что под этим понимается в С++ и когда-то и теперь, это сокрытие части представления и реализации. Результатом является перечень доступных методов и данных которые являются частью внутреннего интерфейса. Внешним интерфейсом являются друзья класса.
Однако, как видно, даже крутые мэны считают инкапсуляцию результатом. Это трудный вопрос, говорить с математиками о причинах и следствиях. Обычно, безнадёжный. Но не всегда. Математики бывают разные.
1
4 / 4 / 0
Регистрация: 26.10.2015
Сообщений: 52
31.08.2019, 21:08  [ТС] 17
Цитата Сообщение от Ygg Посмотреть сообщение
дополнительная фишка сопутствующая инкапсуляции
Мне об этом преподаватель тоже говорил. Я считал, что инкапсуляция - это всего лишь Private, но это действительно есть дополнительным бонусом типа "защиты данных". А инкапсуляция - это намного глубже. "Для того, что бы ездить на машине, не обязательно знать ее устройство(реализацию), достаточно знать то, как можно управлять машиной и что она делает(интерфейс). Если в машине инженеры поменяют двигатель(изменят ее реализацию), то это никак не повлияет на управление этой машины.
0
Комп_Оратор)
Эксперт по математике/физике
8719 / 4428 / 598
Регистрация: 04.12.2011
Сообщений: 13,270
Записей в блоге: 16
31.08.2019, 22:51 18
Цитата Сообщение от Марафет Посмотреть сообщение
Я считал, что инкапсуляция - это всего лишь Private, но это действительно есть дополнительным бонусом типа "защиты данных".
Марафет, секционирование объявлений в теле класса это инструмент сокрытия. Это и есть инкапсуляция в смысле сокрытия реализации. Бонусы трудно перечислить. Возможность независимой модификации реализации от пользовательского (клиентского) кода, это очень важно, но есть ещё кое что. Например ООП реализация в С++. Громко сказано? Я знаю. Но это так и есть. Модульность С далеко не модульность С++. Каждый состоявшийся С-программист объяснит вам вред глобальных переменных. Представьте себе функции без параметров которые работают захватывая переменные из доступных глобальных объявлений. Тут оператор goto который ругают (почём зря) на каждом углу, это мелочь. Код работающий такими функциями, это не спагетти. Это овсянка-размазня. То есть, функции объявляют интерфейс в виде параметров и возвращаемого значения и скрывают реализацию, для борьбы с кашей. Каша, это связность. Самая густая и вязкая каша, это зависимость каждой части от каждой части, - сплошной клейстер. Ни читать, ни отлаживать такой код невозможно в контексте осмысленной и целенаправленной деятельности. С ростом размеров кода, количество связей растёт с комбинаторной скоростью. То есть, количество кода из N строк порождает N! (факториал) - условно говоря, мест откуда может быть модифицирована та или иная глобальная переменная.
То есть, борьба со связностью, это не полезно. Это неизбежно. Инкапсуляция, обеспечиваемая свободными функциями, это способ борьбы со связностью. Повторное использование возможно и на захвате глобальных данных. Но инкапсуляция классов, это способ устранения связности на уровне больших, логически связных модулей. Связность этих модулей можно скрыть внутри этих модулей. Так в С++ всё и сделано. Это позволяет организовывать большие объёмы кода снижая связность до минимума. Лезвие Оккама, это жизненно важный принцип минимальной достаточности, а не неврастеническое желание всё спрятать, чтобы ни кто не узнал. О инварианте класса почитайте самостоятельно, - это поддержании внутренней связности. Раздельно работают только прочные детали конструкции. RAII - вопросы жизненного цикла инкапсулированного контекста. Это уровень программы и это сердце С++. Тоже отдельная тема. Всего, условно говоря, - три уровня абстракции отражается:
-Уровень объекта внешнего мира, отражаемый (проецируемый) в модели. Объекты узлы графа модели, а рёбра - действия, отношения, зависимости;
-Уровень алгоритма, где объекты - наборы данных, а рёбра конкретизированы в функции-сообщения;
-уровень программы, где объекты - участки памяти и кода, имеющие время жизни, захватывающие и освобождающие (владеющие) ресурсы к которым относятся в т.ч. и другими объекты.
Инкапсуляция в обеих её ипостасях обеспечивает базис для жизнеобеспечения всего этого добра. Она позволяет использовать девиз: "Разделяй и властвуй" для использование меньших объектов для строительства более крупных. Это модульность недостижимая для чисто процедурного или чисто функционального стиля.
1
2145 / 690 / 265
Регистрация: 10.02.2018
Сообщений: 1,622
01.09.2019, 00:41 19
Марафет, пример с машиной опять мимо, имхо. IGPIGP прав в неоднозначности трактовки термина. В конце концов, вам сдавать теорию преподавателю, поэтому нужно больше ориентироваться на тот смысл, который именно он вкладывает в этот термин. Моё мнение может не соответствовать этому. Попытаюсь интерпретировать отрывок вашего конспекта на свой лад.

Инкапсуляция поддерживает принцип черного ящика...
Объединение данных и функций для работы с ними в единую сущность (инкапсуляция) помогает (способствует, поддерживает) организовать работу кода по принципу черного ящика. Отсутствие единой сущности (разделение данных и кода для работы с ними) никак само по себе не способствует этому. Инкапсуляция поддерживает принцип черного ящика, но не является сама по себе черным ящиком. Инкапсуляция не равно чёрный ящик. Дальше по конспекту идёт пояснение, что такое чёрный ящик. Вы сосредоточились на принципе черного ящика и таким образом сместили акцент. Пример с машиной - это, опять же, пример чёрного ящика.
1
Комп_Оратор)
Эксперт по математике/физике
8719 / 4428 / 598
Регистрация: 04.12.2011
Сообщений: 13,270
Записей в блоге: 16
01.09.2019, 10:11 20
Цитата Сообщение от Ygg Посмотреть сообщение
. В конце концов, вам сдавать теорию преподавателю, поэтому нужно больше ориентироваться на тот смысл, который именно он вкладывает в этот термин.
Да, согласен. Но попутно можно ознакомиться с областью вокруг концепции. Это не помешает. Тем более, что черный ящик, который принят в качестве базового понятия определения - крайне неудачный ход мысли преподавателя.
Во-первых, использование неопределённых понятий в определении другого понятия должно быть чётко обосновано и минимизировано. Сам принцип инкапсуляции и бритва Оккама этого требуют, кстати. Специализация на области логики (определения это оттуда) тоже требуют от определений определённости от места определения и вплоть до аксиоматических понятий самого верхнего уровня абстракции в данной области (древовидной системе понятий - абстракций).
Во-вторых, чёрный ящик в ООП уже определён. Он определяется через частный случай инкапсуляции - инкапсуляция наследования. Наследование реализации - достаточно специфическая и непростая для понимания вещь и то что преподаватель включил чёрный ящик в своё определение инкапсуляции, говорит о том, что он не просто не понимает закрытого наследования. Он не знает о чёрном ящике в ООП.
Это в целом, обыденная ситуация. Бороться не имеет смысла. В конце концов, люди и их места находятся в механизме спроса-предложения. Кроме того, преподаватель может не знать многих вещей в силу огромного размера языка. То есть, конструктивная позиция в том, чтобы эффективно взять у преподавателя помощь в том, что он знает. Остальное нужно добыть самому. Наш форум, - не плохой способ для этого.
1
IT_Exp
Эксперт
87844 / 49110 / 22898
Регистрация: 17.06.2006
Сообщений: 92,604
01.09.2019, 10:11

Эквивалентность определений
1 Граф связный только когда его нельзя подать, как объединение двух графов. 2 Граф связный, когда...

Lenovo g780 gри разрешение 1600х900 и качестве 720p видео не четкое и размытое. Что делать ?
Ноутбук lenovo g780. При разрешение 1600х900 и качестве 720p видео не четкое и размытое....

gcc не видит определений
У меня есть свой тип, задекларирован с помощью typedef. Все нужные заголовочные файлы подключил в...

Порядок глобальных определений
#include &lt;iostream&gt; using namespace std; class C { public: void f(); }x; void...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
20
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2021, vBulletin Solutions, Inc.