Инкапсуляция и конфликт с преподавателем

Доброго времени суток всем!
Объясню суть происходящего. Я, как студент ВУЗа, недавно провалил попытку сдать зачет по такой дисциплине, как "Теория разработки ПО" (ТРПО). Мне достался вопрос про инкапсуляцию, наследование и полиморфизм.
В общем-то суть этих принципов мне ясна в достаточной мере после изучения различной литературы и применения знаний на практике.
Однако, с преподавателем случился серьезный конфликт, т.к. он, по неизвестной до конца причине, не считается с книжными или энциклопедическими определениями основных принципов ООП.
А проблема тут в том, что подобные книжные определения (с его точки зрения) говорят о том, КАК что-то должно быть реализовано. Т.е. объясняют механизмы реализации, но не отвечают на вопрос ПОЧЕМУ именно так, а не по другому.

Уважаемые знатоки ООП, расскажите тогда мне, каких же объяснений ожидает преподаватель на предмет "почему придумали ООП и конкретно инкапсуляцию". Я, честно говоря, в полной расстерянности, т.к. книжные варианты с его точки зрения не дают полной картины происходящего.

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

Вот что он сам предлагает рассматривать, однако и это не исчерпывающий ответ на его вопрос:

1

Сообщение от TRIG иначе не ясно как тогда разработка вообще была возможной в прошлом без необходимых инструментов

всё предельно ясно - программы были небольшие, программисты были очень умные (и в очень малом количестве), затраты времени были большие

1

Сообщение от Алексей1153 всё предельно ясно - программы были небольшие, программисты были очень умные (и в очень малом количестве), затраты времени были большие

Впрочем, я это и имел ввиду. Тогда и таких масштабов разработки не было, чтобы использовать гипотетический прототип ООП. Ну или о каких годах тогда речь идет? Если это промежуток 60-80х, то да, там уже объекты во всю раскручивались, потому что появилась нарастающая потребность в промышленной разработке, а ПО становилось все тяжелее и тяжелее структурно.
А о том, что ООП как-то имитировалось ранее этого срока - я слышал примерно нихрена, вот честно признаюсь.

Добавлено через 10 минут

Сообщение от Алексей1153 есть ещё вариант - сменить преподавателя. Или отнести его художества ректору

Вот кстати, я не знаю, кто учится тут, а кто уже закончил, но препода сменить в ряде ВУЗов - задача практически нереальная, потому конкретный препод иногда в единственном экземпляре (без привязки к тому, хороший он или нет), да еще и работает за 2 рупия в час.

0

В какой-то момент размеры проектов выросли настолько, что структурное программирование уже плохо справлялось, возникла необходимость использовать что-нибудь более продвинутое. ФП использовать не было возможности, так как функциональный код намного сложнее перевести в машинные коды, чем сишный. Когда у вас компьютер с ОЗУ 4 Мб, то встаёшь перед выбором между "кое-как" и "очень долго". (Для большинства задач ФП подходит лучше, чем ООП. Поэтому все популярные ООП языки развиваются в сторону ФП.)
К тому же с появлением персоналок пошла мода на (псевдо)графический интерфейс, для которого ООП подходит очень хорошо. В результате появилось "классическое ООП" - C++ и Java (которое сильно отличается от "ООП Алана Кея"). Далее я использую "ООП" в значении "классическое ООП".


Изначально ООП определялось как инкапсуляция + наследование + полиморфизм.

инкапсуляция

Под инкапсуляцией в первую очередь подразумевалось объединение методов и свойств в одном объекте. Сокрытие данных рассматривалось как необязательный бонус. Причём, сокрытие есть и в не ООП языках (экспорт функций из модуля, замыкания и т.п.), а объединение обычно используется только в ООП. Получается такая "ООП инкапсуляция".

наследование

Под наследованием подразумевается возможность повторного использования кода путём создания "шаблонов типов" (прототип/класс) из других "шаблонов типов". Далее используем "шаблон типа" для создания экземпляров. Разница между классами и прототипами не принципиальна.

Наследование - это та черта, которая, собственно, и отличает ООП от не ООП. Любой код без "полноценного" наследования не является ОО кодом, даже если написан на "чисто ОО ЯП" типа Java или C#. Полноценное наследование - это наследование реализации метода. То есть, наследование от интерфейса или "полностью абстрактного" класса - это всего лишь способ на ООП языках выразить некую общую (не ООП) идею.

Программирование объектами тоже не является особенностью ООП. В том же Си вполне себе используются объекты. В зарубежной литературе даже есть термин object based programming, который отличается от ООП.

В определении из википедии (взято у Буча):
Объе́ктно ориенти́рованное программи́рование (сокр. ООП) — методология или стиль программирования на основе описания типов/моделей предметной области и их взаимодействия, представленных порождением из прототипов или как экземпляры классов, которые образуют иерархию наследования.
Ключевая фраза здесь - "которые образуют иерархию наследования". Без наследования нет ООП,

полиморфизм

Под полиморфизмом в ООП подразумевается исключительно полиморфизм подтипов. Специализированный ("неполноценный") полиморфизм (перегрузка методов, неявное приведение типов) используется и в структурном программировании. Параметрический полиморфизм используется в ФП. Штука настолько хорошая, что позже его добавили и в ООП в виде обобщённых классов и методов. А ООП - это про полиморфизм подтипов.

Почему

Изначально написали графический ООП интерфейс. Получилось настолько хорошо, что решили приспособить идею и для других задач. В качестве обоснования сказали, что 1) всё вокруг объекты и 2) эти объекты образуют иерархию. Здесь "объекты" - в ООП смысле, то есть, действия привязаны к объектам. Кошки мяукают, собаки лают - и те, и те животные. У треугольника площадь и у прямоугольника площадь - и те, и те фигуры. Примерно такие примеры можно было встретить в ранних ООП учебниках. Правда, потом выяснилось, что иерархия в обычном понимании не подходят для ООП, да и нет вокруг никакой иерархии - есть признаки (атрибуты). Учебник на русском языке по алгоритмам на примере Java - попробуйте выстроить иерархию. Квадрат является прямоугольником, но только не в ООП смысле. Документ не сохраняет себя (метод Sava), а есть некий "сохранятель", причём, иерархия сохранятелей (например, репозиториев) никак не связана с иерархией документов. Поэтому стали отделять данные от методов, добавлять в ООП языки ФП черты, создавать реактивные интерфейсы и так далее. А новые языки, скорее уже "ФП с чертами ООП", чем "ООП с чертами ФП".

3

Сообщение от Shamil1 Почему Изначально..

Написали хорошо. И этот абзац, и весь пост (язык правилен и чист, автор даже обладает слогом). Но вот ответ на "почему" как-то не звучит. "Потому что хорошо получился графический интерфейс" - не воспринимается серьезно. Хотя что-то в этом есть - напр в инженерных задачах с тем же полиморфизмом не густо. Поэтому лучше всего подходит первая фраза

Сообщение от Shamil1 В какой-то момент размеры проектов выросли настолько, что структурное программирование уже плохо справлялось, возникла необходимость использовать что-нибудь более продвинутое.

Да, глуповатое "все вокруг классы" все-таки лучше чем ничего, оно позволяет хоть как-то упорядочить и рулить (большим) кодом. Возьмем любое приложение/либу на С/С++, попробуем как-то "без классов". Получим "спагетти", "лапшу" и.т.п. непригодные к использованию

Сообщение от Shamil1 ФП использовать не было возможности, так как..

То уже сказки про белого ФП бычка

1

Сообщение от Igor3D "Потому что хорошо получился графический интерфейс" - не воспринимается серьезно.

Было время ("доинтернетное"), когда единственным доступным учебником по ООП была методичка "как писать ГУИ на Борладнд С++". И на тот момент это, действительно, было прорывом (для конкретной задачи).

Сообщение от Igor3D напр в инженерных задачах с тем же полиморфизмом не густо

Даже в бизнес-задачах не густо. От паттерна "активная запись" давно отказались, используют Plain Old CLR Object (POCO). А методы складывают в специальные классы, в которых из свойств только настройки конфигурации. Наследование, кроме фреймворков, почти нигде не используется. Зато ключевое слово "readonly", записи, сопоставление с образцом, локальные функции, повторно используемый код в методах расширения и т.д. и т.п.

1

Сообщение от korvin_ Откуда кто-то может знать, что в голове у твоего преподавателя?

я знаю.

препод видит, что чувак не ходил на его лекции и на сдачах пытается городить свои огороды.
а почему не ходил то? "потому что меня - препода не уважает."
ну тогда:

0

Инкапсуляция (от лат. in capsule — в оболочке) — это заключение данных и функционала в оболочку. (Из поиска Яндекса)

Суть: есть два метода Draw и Show. Есть две переменных Image, BackColor.
Объединить в одну оболочку - это значит дать им всем общее имя.

Object_Draw()
Object_Show()
Object_Image
Object_BackColor

Вот так бы я делал без ООП. Но ООП позволяет делать так:

Object.Draw()
Object.Show()
Object.Image
Object.BackColor

Разница в том, что мы один раз объявляем имя Object и по одному разу - члены/методы. То есть соблюдаем правило DRY.

0

Меня удивляет, что никто не упомянул динамическую память.

Добавлено через 1 минуту
Словари и полиморфизм были и в Форте

Добавлено через 1 минуту
Без возможности порождать инстанты в полете - ООП - гуно

1

Сообщение от TRIG почему придумали ООП

ИМХО. Вообще двигателем прогресса является человеческая лень и непомерное любопытство, нам лень мыть посуду (чисто женский взгляд)) - придумали посудомойки, лень стирать - придумали стиральные машины и т.д. и т.п., создавая что-то одно выясняется, что это можно применить и для другого, тем самым умножая комфорт и удобство, облегчая человеческий труд и быт. Думаю ООП не исключение. Он был создан потому, что приходилось писать много кода, отслеживать кучу переменных, а когда у тебя десятки или сотни массивов (без ООП все сидело в массивах в основном), то с легкостью можно было пропустить проверить или изменить какие-либо данные. Это в свою очередь вызывало необходимость отладки, а с таким количеством данных, процесс превращался в сущий ад. Вот тут чуть подробнее о ООП

2

Сообщение от TRIG "почему придумали ООП и конкретно инкапсуляцию".

Вы не только книжки/википедии не читайте, но и не слушайте местных форумчан, для которых объект - это нечто, что передаёт сообщения другим объектам.

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

Когда вы копируете, Object в Object2, то не задумываетесь, что копируете Draw(), Show(), Image и BackColor.

Но совсем примитивно-древняя потребность в инкапсуляции - это чтобы родственные функции и переменные группировались рядом при лексикографическом порядке.

0

Сообщение от Shamil1 К тому же с появлением персоналок пошла мода на (псевдо)графический интерфейс, для которого ООП подходит очень хорошо. В результате появилось "классическое ООП" - C++ и Java

Только небольшое уточнение: оно («классическое ООП») появилось раньше, до (псевдо)графических интерфейсов (Simula 67).

Сообщение от Shamil1 Изначально написали графический ООП интерфейс.

Только ещё одно небольшое уточнение: его написали не на «классическом ООП», но на «ООП Алана Кея, которое сильно отличается» (SmallTalk, Xerox PARC). Apple для внедрения этих ГУИ-идей в свои компьютеры использовала Object Pascal, который ближе к «классическому», да. Но в последствии, сначала в Next, а потом и в MacOS 10, перешли на Objective C, который реализовывал более SmallTalk-подобное ООП.

1

Какая мощная струя ответов! Все-таки интересно, а чего хотел препод? Вряд ли мы это узнаем, обычно интерес к форуму чисто утилитарный, типа "нажрался и отвалил". Ну как знать...

0

Сообщение от korvin_ Только ещё одно небольшое уточнение: его написали не на «классическом ООП», но на «ООП Алана Кея, которое сильно отличается»

Я специально пропустил этот момент. Де факто в начале 21 века господствовало ООП а ля C++/Java. Оно, как Вы правильно говорите, сильно отличается от того ООП, что было до этого. Я беру придуманный мной термин "классическое ООП" в кавычки, чтобы избежать дискуссий о том, какое именно ООП правильнее называть классическим. Я выбрал самое массовое на начало 21 века.

Добавлено через 4 минуты

Сообщение от Mikhaylo Инкапсуляция (от лат. in capsule — в оболочке) — это заключение данных и функционала в оболочку.

Да. Именно это называют инкапсуляцией в "классическом ООП". Но, если брать Информатику в целом, то этот термин имеет другое значение. Поэтому "инкапсуляция" и "инкапсуляция" - это разные вещи.

1

Сообщение от XLAT препод видит, что чувак не ходил на его лекции и на сдачах пытается городить свои огороды.

Я вообще на каждой лекции был. Так что прежде чем выводы делать - лучше уточнить чем автор занимался.
А "огороды городить" - это что вообще? Т.е. научное определение из учебных пособий уже превратилось в "горожение огородов"?
Вообще без разницы статус человек, ссылаться можно только на научные источники, а не на себя любимого и свое понимание вопроса.

Сообщение от Mikhaylo Вы не только книжки/википедии не читайте, но и не слушайте местных форумчан, для которых объект - это нечто, что передаёт сообщения другим объектам.

Вы видимо и ветку то не читали, а-ля лишь бы свои пять копеек вставить.

Сообщение от Igor3D Все-таки интересно, а чего хотел препод? Вряд ли мы это узнаем, обычно интерес к форуму чисто утилитарный, типа "нажрался и отвалил".

Тут прям про проекции вспомнить актуально.
Естественно, раз я сказал что уточню ответ как придет время - я так и поступлю. Как вы поступаете - ко мне отношения не имеет.

Время как раз пришло.
Верный ответ на самый важный и сложный вопрос в мире...

Пишу прям дословно:

Инкапсуляция - это способ сузить область поиска ошибки (в программном коде).

Если еще дополнить комментариями, то инкапсуляция нужна, чтобы при возникновении ошибки, программист не пошел исправлять всё подряд в коде, и сузил область её поиска.

Сообщение от Tanya2007 Он был создан потому, что приходилось писать много кода, отслеживать кучу переменных, а когда у тебя десятки или сотни массивов (без ООП все сидело в массивах в основном), то с легкостью можно было пропустить проверить или изменить какие-либо данные. Это в свою очередь вызывало необходимость отладки, а с таким количеством данных, процесс превращался в сущий ад.

Ваш ответ наиболее близок к верному, потому что рассматривает инкапсуляцию не просто как удобный инструмент с точки зрения структурирования данных, но и с точки зрения возникновения/поиска/отладки ошибок в программном коде. Прям к массивам из прошлого это не имеет прямого отношения, но имеет отношение к исправлению кода, а-ля "я точно не накосячил в структуре и ошибка где-то в другом месте".
___________________

Всем остальным выражаю благодарность за свои ответы и попытки помочь разобраться.

1

Сообщение от TRIG Инкапсуляция - это способ сузить область поиска ошибки (в программном коде).

да да, как раз в инкапсуляциях ошибку искать не надо, поэтому область суживается

0

Сообщение от Алексей1153 да да, как раз в инкапсуляциях ошибку искать не надо, поэтому область суживается

Это и есть основной ответ на вопрос "ПОЧЕМУ/ЗАЧЕМ" придумали инкапсуляцию в частности и ООП в общем.
Тут пометка - это НЕ ответ на вопрос "КАК работает/устроена/реализована". Именно второй ответ можно поголовно встретить в учебных пособиях разных лет (пришлось сверяться еще несколько раз).

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

Добавлено через 2 минуты

Сообщение от vantfiles Меня удивляет, что никто не упомянул динамическую память.

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

0

Сообщение от TRIG Пишу прям дословно: Инкапсуляция - это способ сузить область поиска ошибки (в программном коде).

То есть без ООП искать ошибки было очень трудно, иной раз невозможно. А вот с ООП намного легче! Дело оказывается в "поиске ошибок".

Сообщение от TRIG Верный ответ..

Сообщение от TRIG Ваш ответ наиболее близок к верному...

А чего Вы считаете его "верным"? Никаких особых оснований для этого не видно, напр с тем же успехом можно утверждать типа "код лучше структурирован", отсюда и ошибки искать легче, никакой специальной диагностики ООП не предоставляет. Или Вы "ничего не считаете", цель - сдать?

Сообщение от TRIG Насколько такой ответ можно рассматривать с точки зрения корректности на экзамене у конкретного преподавателя - я судить не буду,

Ну значит он Вас уже чему-то научил

Сообщение от Tanya2007 а когда у тебя десятки или сотни массивов (без ООП все сидело в массивах в основном)

Та ну нафиг, "структуры" были задолго до ООП. И сейчас есть либы мощные и уважаемые (напр GStreamer) "без всякого ООП" (во всяком случае формально), хотя таких не так уж много

1

Сообщение от Igor3D А чего Вы считаете его "верным"?

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

Сообщение от Igor3D Или Вы "ничего не считаете", цель - сдать?

Я изучал ООП уже давно. Перед экзаменом читал еще раз, еще более глубоко. Потом после завала читал ваши ответы и ваши материалы (кто давал ссылки). А потом, как говорится, прозрел от ответа преподавателя на предмет того, что же лично он сам хочет в этом ответе слышать и что именно является критерием сдачи.

Однако, сам преподаватель в той же самой лекции где и сидел заветный ответ сказал, что (почти дословно):

"...учебный материал для вас читал перед лекцией через 3 страницы..."

Кто не верит в такое - готов и сам ответ и его дальнейший комментарий про лекции скинуть в виде аудио (в ЛС).

Сообщение от Igor3D Никаких особых оснований для этого не видно, напр с тем же успехом можно утверждать типа "код лучше структурирован", отсюда и ошибки искать легче, никакой специальной диагностики ООП не предоставляет.

Мое личное мнение - такой ответ не то, чтобы неверный, но его смысл далек от изначальной концепции ООП/инкапсуляции, и уже как вы заметили - "поиск ошибок" это не основное назначение инкапсуляции, а скорее её побочный продукт и то не всегда, потому что, как минимум:
1. Саму инкапсуляцию можно поломать самыми разными способами (в зависимости от ЯП), а то и вовсе позабыть что-то инкапсулировать, но по-умолчанию при таком подходе будет считаться, что ошибка где-то в другом месте. И подобное наоборот увеличит время на поиск этой самой ошибки.
2. Что облегчает работу, то её может и усложнить, в зависимости от ситуации. И банально было бы думать, что найдена "таблетка от всех проблем".
К тому же да, таких побочных продуктов можно найти огромное множество и не только ООП их будет генерировать, что делает обсуждение подобных вопросов довольно абсурдным из-за своего огромного разнообразия и при этом низкой практической пользы.
Мне лично больше понравились ответы от местной публики, я бы отдал им приоритет, но с учетом всяких пометок, что "...в ряде случаев проще будет отыскать ошибку, если...".
В целом же, я сам не эксперт и не специалист, чтобы совершенно точно и однозначно утверждать, что "уж теперь-то я наверняка знаю что такое инкапсуляция и зачем она нужна". Мои знания и опыт сильно ограничены, чего я не скрываю.

2

Сообщение от TRIG Вы видимо и ветку то не читали, а-ля лишь бы свои пять копеек вставить.

Обижаете. Извиняйтесь.

Сообщение от TRIG инкапсуляция нужна, чтобы при возникновении ошибки, программист не пошел исправлять всё подряд в коде, и сузил область её поиска.

Неполный ответ, соответственно неправильный. Еще инкапсуляция нужна, чтобы уменьшить количество ошибок, чтобы не приходилось их исправлять.

0

TRIG, прочитайте в лекциях своего преподавателя, если их нет - перепишите. Он не может с вас требовать того, чему вас не учил.

0