Лекция
Привет, Вы узнаете о том , что такое класс, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое класс, класс как структура данных , настоятельно рекомендую прочитать все из категории Объектно-ориентированное программирование ООП.
класс ы, а не объекты - предмет обсуждения
Какова центральная концепция объектной технологии? Необходимо дважды подумать, прежде чем ответить "объект". Объекты полезны, но в них нет ничего нового.
С тех пор, как структуры используются в Cobol, с тех пор, как в Pascal существуют записи, с тех пор как программист написал на C первое определение структуры, человечество располагает объектами.
Объекты важны при описании выполнения ОО-систем. Но базовым понятием объектной технологии является класс. Обратимся вновь к его определению. (Детальное обсуждение объектов содержится в следующей лекции.)
Класс - это абстрактный тип данных, поставляемый с возможно частичной реализацией.
Абстрактные типы данных (АТД) являются математическим понятием, пригодным на этапе подготовки спецификации - в процессе анализа. Понятие класса, предусматривая частичную или полную реализацию, обеспечивает необходимую связь с разработкой ПО на этапах проектирования и программирования. Напомним, класс называется эффективным, если его реализация полна, и отложенным - при частичной реализации.
Аналогично АТД, класс - это тип, описывающий множество возможных структур данных, называемых экземплярами (instances) класса. Экземпляры АТД являются абстракциями - элементами математического множества. Экземпляр класса конкретен - это структура данных, размещаемая в памяти компьютера и обрабатываемая программой.
Например, если определить класс STACK, взяв за основу спецификацию АТД из предыдущей лекции и добавив информацию, необходимую для адекватного представления, то экземплярами класса будут структуры данных - конкретные стеки. Другим примером является класс POINT, моделирующий точку на плоскости. Если для представления точки выбрана декартова система координат, то каждый экземпляр POINT представляет собой запись с полями x, y - абсциссой точки и ее ординатой.
Термин "объект" появляется как побочный продукт определения "класса". Объект это просто экземпляр некоторого класса.
Программные тексты, описывающие создаваемую систему, содержат определения классов. Объекты создаются только в процессе выполнения программ.
Настоящая лекция посвящена основным приемам создания программных элементов и объединения их в системы, именно поэтому в центре внимания - классы. В следующей лекции будут рассмотрены структуры периода выполнения, порождаемые ОО-системой, что потребует изучения некоторых особенностей реализации и более детального рассмотрения природы объектов.
Класс - это модель, а объект - экземпляр такой модели. Эта особенность настолько очевидна, что обычно не требует дополнительных комментариев. Тем не менее, в определенной категории специальной литературы имеет место весьма небрежное обращение с этими понятиями, - смешиваются понятие отдельного объекта и концепция объектов в целом, которую характеризует класс. У этой путаницы два источника. Один - возникает из-за широкого толкования термина "объект" в естественном языке. Другой источник недоразумений связан с метаклассами, - с ситуациями, когда классы сами выступают в роли объектов. Классическим примером может служить транслятор объектного языка, для которого классы языка являются объектами трансляции.
Некоторые ОО-языки, особенно Smalltalk, для выхода из рассмотренной ситуации используют понятие метакласс (metaclass). Метакласс - это класс, экземпляры которого сами являются классами. В романе "Имя Розы", отрывок из которого приведен в эпиграфе к данной лекции, встречается понятие "знаки знаков". По сути, это и есть неформальное определение метаклассов.
Мы будем избегать введения метаклассов, поскольку создаваемых ими проблем больше, чем тех, которые они решают. В частности, введение метаклассов создает трудности при проведении статической проверки типов, что является необходимым условием разработки надежного ПО. Основные функции метаклассов могут быть гораздо лучше реализованы с помощью других средств:
В данной книге не используется самостоятельная концепция метакласса. Присутствие метаклассов в том или ином языке или среде разработки не оправдывает смешение понятий моделей и их экземпляров - классов и объектов.
Затратив немного времени на устранение абсурдных, но распространенных и вредных заблуждений, можно вернуться к рассмотрению центральных свойств классов и выяснить, в частности, почему они столь важны в объектной технологии.
Для понимания ОО-подхода необходимо ясно представлять, что классы выполняют две функции, которые до появления ОО-технологий всегда были разделены. Класс одновременно является модулем и типом.
Средства, используемые при разработке ПО, - языки программирования, проектирования, спецификаций, графические системы обозначений для анализа, - всегда включали в себя как возможность применения модулей, так и систему типов.
Модули - это структурные единицы, из которых состоит программа. Различные виды модулей, такие как подпрограммы и пакеты, рассматривались в одной из предыдущих лекций (см. ). Независимо от конкретного выбора той или иной модульной структуры, модуль всегда рассматривается как синтаксическая концепция. Отсюда следует, что разбиение на модули влияет лишь на форму записи исходных текстов программ, но не определяет их функциональность. В самом деле, принципиально можно написать программу Ada в виде единственного пакета, или программу Pascal как единую основную программу. Безусловно, такой подход не рекомендуется, и любой компетентный программист будет использовать модульные возможности языка для деления программы на обозримые и управляемые части. Но если взять существующую программу, например на Паскале, то всегда можно собрать воедино все модули и получить работоспособную программу с эквивалентной семантикой. (Присутствие рекурсивных подпрограмм делает этот процесс менее тривиальным, но не оказывает принципиального влияния на данную дискуссию.) Таким образом, деление на модули диктуется принципами управления проектами, а не внутренней необходимостью.
Концепция типов на первый взгляд совершенно иная. Тип является статическим описанием вполне определенных динамических объектов - элементов данных, которые обрабатываются во время выполнения программной системы. Набор типов обычно содержит предопределенные типы, такие как INTEGER или CHARACTER, а также пользовательские типы: записи (структуры), указатели, множества (в Pascal), массивы и другие. Понятие типа является семантической концепцией, и каждый тип непосредственно влияет на выполнение программной системы, так как описывает форму объектов, которые система создает и которыми она манипулирует.
В не ОО-подходах концепции модуля и типа существуют независимо друг от друга. Наиболее замечательным свойством класса является одновременное использование обеих концепций в рамках единой лингвистической конструкции. Класс является модулем или единицей программной декомпозиции, но одновременно класс это тип (или шаблон типа в тех случаях, когда поддерживается параметризация).
Мощь ОО-метода, во многом, следствие этого отождествления. Наследование, в частности, может быть полностью понято только при рассмотрении его, как модульного расширения, так и, одновременно, уточнения специализации типа.
Как практически соединить две столь различные на первый взгляд концепции? Последующая дискуссия и примеры позволят ответить на этот вопрос.
Важным аспектом ОО-подхода является простота и универсальность системы типов, которая строится на основе фундаментального принципа.
Каждый объект является экземпляром некоторого класса
Объектный принцип будет распространяться не только на составные объекты, определяемые разработчиками (такие как структуры данных, содержащие несколько полей), но и на базовые объекты - целые и действительные числа, булевы значения и символы, которые будут рассматриваться как экземпляры предопределенных библиотечных классов (INTEGER, REAL, DOUBLE, BOOLEAN, CHARACTER).
На первый взгляд подобное стремление превратить любое сколь угодно простое значение в экземпляр некоторого класса может показаться преувеличенным и даже экстравагантным. В конце концов, математики и инженеры в течение многих лет успешно используют целые и действительные числа, не подозревая о том, что они работают с экземплярами классов. Однако настойчивое требование к унификации вполне окупается по ряду причин.
| Пример наследования - классы INTEGER , REAL и DOUBLE могут быть наследниками двух более общих классов; NUMERIC , в котором определены основные арифметические операции ("+", "-", "*"); COMPARABLE , представляющий операции сравнения ("<" и другие). В качестве примера использования универсализации можно рассмотреть родовой класс MATRIX , родовой параметр которого определяет тип элементов матрицы. Экземпляры класса MATRIX [INTEGER] будут целочисленными матрицами, а экземпляры MATRIX [REAL] будут в качестве элементов содержать действительные числа. В качестве комплексного примера одновременного использования наследования и родовых классов можно использовать класс MATRIX [NUMERIC] , экземпляры которого могут содержать элементы типа INTEGER или REAL или любого нового типа T , определенного разработчиком как наследника класса NUMERIC . |
При условии хорошей реализации нет необходимости опасаться каких-либо негативных последствий решения определять все типы как классы. Ничто не мешает предоставить компилятору специальную информацию о базовых классах. В этом случае порождаемый код для операций со значениями классов INTEGER и BOOLEAN может быть столь же эффективным, как если бы они были встроенными типами данного языка.
Построение непротиворечивой и универсальной системы типов требует комплексного применения ряда важных ОО-методик, которые будут рассмотрены позже. К их числу относятся расширяемые классы, гарантирующие корректное представление простых значений; инфиксные и префиксные операции, обеспечивающие возможность использования привычного синтаксиса (a < b или -a вместо неуклюжих конструкций a.less_than (b) или a.negated); ограниченная универсализация, необходимая для описания классов, адаптируемых к типам со специфическими операциями. Например, класс MATRIX может представлять целочисленные матрицы, а также матрицы, элементами которых являются числа других типов.
Что представляет собой класс можно выяснить, изучая простой, но типичный пример, который демонстрирует фундаментальные свойства, применимые практически ко всем классам.
Пример использует представление точки в двумерной графической системе:
Рис. 7.1. Точка и ее координаты
Для определения типа POINT как абстрактного типа данных потребуется четыре функции-запроса: x, y, ρ, θ. (В текстах подпрограмм для двух последних функций будут использоваться имена rho и theta). Функция x возвращает абсциссу точки (горизонтальную координату), y - ординату (вертикальную координату), ρ - расстояние от начала координат, θ - полярный угол, отсчитываемый от горизонтальной оси. Значения x и y являются декартовыми, а ρ и θ - полярными координатами точки. Другой полезной функцией является distance, возвращающая расстояние между двумя точками.
Далее спецификация АТД будет содержать такие команды, как translate (перемещение точки на заданное расстояние по горизонтали и вертикали), rotate (поворот на определенный угол вокруг начала координат) и scale (уменьшение или увеличение расстояния до начала координат в заданное число раз).
Нетрудно написать полную спецификацию АТД, включающую указанные функции и некоторые ассоциированные аксиомы. Далее в качестве примера приведены две из перечисленных функций:
x: POINT REAL
translate: POINT × REAL × REAL POINT
и одна из аксиом:
x (translate (p1, a, b)) = x (p1) + a
утверждающая, что для произвольной точки p1 и действительных значений a и b при трансляции точки на абсцисса увеличивается на a.
Читатель, если пожелает, может самостоятельно завершить спецификацию АТД. В дальнейшей дискуссии подразумевается, что вы понимаете, как устроен данный АТД, вне зависимости от того, написали ли вы его полную формализацию или нет. Сосредоточим внимание на реализации АТД - классе.
Любой абстрактный тип данных и POINT в частности характеризуется набором функций, описывающих операции применимые к экземплярам АТД. В классе, реализующем АТД, функции становятся компонентами (features) - операциями, применимыми к экземплярам класса.
В было показано, что в АТД существуют функции трех видов: запросы (queries), команды (commands) и конструкторы (creators). Для компонентов классов необходима дополнительная классификация, основанная на том, каким образом реализован данный компонент - в пространстве или во времени (by space or by time). (См. "Категории функций", )
Пример координат точки отчетливо демонстрирует эту разницу. Для точек доступны два общепринятых представления - в декартовых или полярных координатах. Если для представления выбрана декартова система координат, то каждый экземпляр класса содержит два поля представляющих координаты x и y соответствующей точки:
Рис. 7.2. Представление точки в декартовых координатах
Если p1 является такой точкой, то получение значений x и y сведется просто к просмотру соответствующих полей данной структуры. Однако определение значений ρ и θ требует вычисления выражения √(x 2 + y 2 ) для ρ и arctg (y/x) для θ (при условии ненулевого x).
Использование полярной системы координат () приводит к противоположной ситуации. Теперь ρ и θдоступны просто как значения полей, а определение x и y возможно после простых вычислений (ρ cosθ, ρ sinθ, соответственно).
Рис. 7.3. Представление точки в полярных координатах
Приведенный пример указывает на необходимость рассмотрения компонентов двух видов:
Вторая категория - подпрограммы - нуждается в дальнейшей дополнительной классификации. Часть подпрограмм возвращает результат, и их называют функциями (functions). В приведенном примере функциями являются x и y в представлении в полярных координатах, в то время как rho и theta - функции в декартовых координатах, все они возврвщают результат типа REAL. Подпрограммы, не возвращающие результат, соответствуют командам в спецификации АТД и называются процедурами (procedures). Например, класс POINT содержит процедуры translate, rotate и scale.
| Не следует путать понятие "функция", обозначающее в классах программу, возвращающую результат, с использованным ранее толкованием функции как математического описания операций АТД. Эта досадная путаница понятий обусловлена устоявшейся терминологией в математике и программировании. |
На дана рассмотренная выше классификация, представленная в виде дерева:
Рис. 7.4. Классификация компонентов класса по их роли
Эта классификация является внешней, основанной на том, каким образом данный компонент выглядит для использующего его клиента.
Можно предложить другую, внутреннюю классификацию, использующую в качестве основного критерия способ реализации компонента в классе:
Рис. 7.5. Классификация компонентов класса по способу реализации
На первый взгляд один из аспектов приведенной выше классификации может вызывать беспокойство. Во многих случаях необходимо иметь возможность работать с объектом, например с точкой p1, не заботясь о том, какое внутреннее представление используется для p1 - декартово, полярное или иное. Необходимо ли для этого отличать атрибуты от функций?
Ответ зависит от того, с какой точки зрения рассматривать данную проблему - разработчика, автора данного класса POINT или клиента, создавшего класс, использующий POINT. Для разработчика разница между атрибутами и функциями принципиально важна и имеет смысл. Ему необходимо принимать решения о том, какие компоненты будут реализованы как данные в памяти и какие будут доступны в результате вычислений. Но заставлять клиента осознавать эту разницу, было бы серьезной ошибкой. Клиент должен обращаться к значениям x или ρ для точки p1, не заботясь и не имея информации о том, как реализованы соответствующие запросы.
Решение проблемы дает принцип унифицированного доступа (Uniform Access principle), введенный в дискуссии о модульности (). Принцип декларирует, что клиент должен иметь возможность доступа к свойствам объекта, используя одинаковую нотацию, вне зависимости от того, как это свойство реализовано - в памяти или как результат вычислений (в пространстве или во времени, в виде атрибута или подпрограммы). Этому важному принципу необходимо следовать при разработке нотации для обращения к компонентам класса. Так выражение, обозначающее значение компонента x объекта p1 будет всегда записываться в виде:
p1.x
вне зависимости от того, осуществляется ли доступ к полю данных объекта или выполняется подпрограмма.
| При использовании такой нотации неопределенность может возникать только для запросов без аргументов, которые могут быть реализованы и как функции и как атрибуты. Команда должна быть процедурой, запрос с аргументами должен быть функцией, так как атрибуты не могут иметь аргументов. |
Принцип унифицированного доступа необходим для гарантирования автономности компонентов ПО. Он защищает право создателя класса свободно экспериментировать с различными способами реализации, не создавая помех клиентам. (СМ. "Использование утверждений для документирования: краткая форма класса", )
| Pascal, C и Ada нарушают этот принцип, предоставляя различную нотацию для вызова функций и для доступа к атрибутам. Это объяснимо для таких не ОО-языков (хотя еще в 1966 г. синтаксис Algol W предшественника Pascal удовлетворял этому принципу). Более новые языки, такие как C++ и Java, также не следуют этому принципу. Отход от этого принципа может служить причиной того, что изменения внесенные во внутренние представления (например переход от полярной системы координат к декартовой или иные) повлекут за собой неработоспособность многих клиентских классов. Это является одной из причин нестабильности программных разработок. |
Принцип унифицированного доступа является источником определенных требований и к подготовке документации. Последовательное применение этого принципа должно гарантировать, например, что в официальной документации не содержится сведений о том, является ли данный запрос без аргументов функцией или атрибутом. Это одно из требований к стандартной методике документирования классов, известной как краткая форма класса.
Ниже приведена версия исходного текста класса POINT. Фрагменты, начинающиеся с двух тире "--", представляют собой комментарии, продолжающиеся до конца строки. Комментарии содержат пояснения, облегчающие понимание текста, и не влияют на семантику класса.
indexing description: "Точка на плоскости" class POINT feature x, y: REAL -- Абсцисса и ордината rho: REAL is -- Расстояние до начала координат (0, 0) do Result := sqrt (x^2 + y^2) end theta: REAL is -- Полярный угол do -- Предлагается реализовать в качестве упражнения (упр. У7.3) end distance (p: POINT): REAL is -- Расстояние до точки p do Result := sqrt ((x - p.x)^2 + (y- p.y)^2) end translate (a, b: REAL) is -- Перемещение на a по горизонтали, b по вертикали do x := x + a y := y + b end scale (factor: REAL) is -- Изменение расстояния до начала координат в factor раз do x := factor * x y := factor * y end rotate (p: POINT; angle: REAL) is -- Поворот вокруг p на угол angle do -- Предлагается реализовать в качестве упражнения (упр. У7.3) end end
Некоторые аспекты приведенного текста неочевидны и требуют дополнительных разъяснений.
Класс в основном состоит из предложения, перечисляющего различные компоненты, вводимого ключевым словом feature. Кроме того, присутствует предложение indexing дающее общее описание (description), полезное для понимания функциональности класса, но никак не влияющее на семантику исполнения. Позднее будут рассмотрены три дополнительных предложения: inherit - для наследования; creation - при необходимости использования специального конструктора; invariant - для объявления инвариантов класса. Будет рассмотрена также возможность включения в класс двух или более предложений feature.
Класс POINT демонстрирует ряд приемов, которые будут использованы в последующих примерах. Необходимо оговорить основные соглашения.
Компоненты x и y объявлены как относящиеся к типу REAL без ассоциированного алгоритма, следовательно, они являются атрибутами. Все остальные компоненты содержат конструкции вида
is do ... Инструкции ... end
которые описывают алгоритм, что является признаком подпрограмм. Подпрограммы rho, theta и distance возвращают результат типа REAL во всех трех случаях, что отражено в объявлениях вида
rho: REAL is ...
Это определяет их как функции. Две другие подпрограммы, translate и scale, не возвращают результата (объявление не завершается конструкцией: T, где T некоторый тип) и, соответственно, являются процедурами.
Поскольку x и y являются атрибутами, а rho и theta функциями, данный конкретный класс использует для представления точки декартову систему координат.
Тело подпрограммы (предложение do) представляет собой последовательность инструкций. Можно разделять последовательные инструкции и объявления точкой с запятой в традициях Algol-Pascal, но это не обязательно. Далее с целью упрощения точка с запятой будет опускаться между элементами на отдельных строках, но всегда будет использоваться как разделитель нескольких инструкций или объявлений в одной строке. (См. "Война вокруг точек с запятой", курса "Основы объектно-ориентированного проектирования")
В подпрограммах класса POINT все инструкции являются присваиваниями значений. В данной нотации для обозначения присваивания используется символ ":=" также следуя соглашениям, принятым в Algol и Pascal. Этот символ нельзя перепутать с символом равенства "=", применяемым, как и в математике, в операциях сравнения.
Другое соглашение о нотации касается использования комментария к заголовку подпрограммы. Уже отмечалось, что комментарии начинаются с двух последовательных тире "--". Они могут размещаться в любом месте, где, по мнению автора, дополнительные разъяснения могут принести пользу. Особую роль играет комментарий к заголовку (header comment). В соответствии с общим стилевым правилом он должен помещаться в начале каждой подпрограммы после ключевого слова is с отступом как в примере класса POINT. Комментарий к заголовку должен кратко отражать назначение подпрограммы.
Атрибуты также сопровождаются комментариями, следующими непосредственно за их объявлением и имеющими тот же отступ, что и комментарии к заголовку подпрограмм. Иллюстрацией могут служить объявления x и y.
В начале нашего класса помещено предложение, начинающееся с ключевого слова indexing. Оно содержит единственный пункт, помеченный как description. Предложение indexing не оказывает влияния на выполнение программ и служит для размещения информации, ассоциированной с классом. В общем случае оно содержит ноль или более пунктов вида
index_word: index_value, index_value, ...
где index_word - произвольный идентификатор (элемент индексирования), а каждое значение index_value - произвольный элемент языка (идентификатор, целое число, строка и т.д.) (См. "Заметки об indexing", ).
Это дает два преимущества:
Приведенный пример содержит единственный индексный элемент - description, значение которого - строка, описывающая назначение класса. Все примеры классов в данной книге будут также содержать элемент description. Настоятельно рекомендуется следовать этому примеру и начинать исходный текст любого класса с предложения indexing, дающего краткую характеристику класса по аналогии с тем, как каждая подпрограмма начинается с комментария к заголовку.
Предложения indexing и комментарии к заголовку являются иллюстрацией правильного применения принципа самодокументирования (Self-Documentation principle): везде, где это возможно, документация модуля должна размещаться непосредственно в самом модуле. (См. "Самодокументирование", )
Для понимания текстов функций rho, theta и distance в классе POINT необходимо еще одно соглашение.
Любой язык программирования, поддерживающий функции (подпрограммы, возвращающие результат) должен предусматривать нотацию, позволяющую установить в теле функции значение, возвращаемое в результате ее вызова. В качестве значения, возвращаемого функцией, в данной книге будет использоваться предопределенная сущность (entity) Result. (Полное определение сущности будет дано в конце этой лекции.)
Например, тело функции rho содержит следующее присваивание
Result := sqrt (x^2 + y^2)
Result - зарезервированное слово, которое может присутствовать только в теле функций. В функции, возвращающей результат типа T, Result рассматривается наряду с другими сущностями и ему может быть присвоено значение с помощью инструкций присваивания, как это показано выше.
При любом вызове функции в качестве результата будет возвращаться последнее присвоенное Result значение. Оно всегда определено благодаря правилам языка (они будут детально рассмотрены позже), требующим обязательной инициализации Result в начале каждой подпрограммы путем присваивания значения, предопределенного типом T. Для типа данных REAL инициализирующее значение равно нулю и следующая функция:
non_negative_value (x: REAL): REAL is
-- Возвращает значение аргумента при x>0; ноль при x<=0
do if x > 0.0 then Result := x end end
будет всегда возвращать вполне определенное значение (как указано в комментарии к заголовку), несмотря на то, что условная инструкция не содержит части else.
Дискуссия в конце данной лекции обсуждает логику использования соглашения Result в сопоставлении с другими приемами, такими как инструкции возврата. Хотя это соглашение касается всех языков программирования, оно является особенно важным при ОО-подходе.
Исходные тексты классов в данной книге строго подчиняются основным правилам стиля. Они регламентируют отступы, шрифты, выбор имен классов и их компонент, использование нижнего и верхнего регистров.
Далее этим правилам будет уделяться серьезное внимание, а их подробному обсуждению полностью посвящена курса "Основы объектно-ориентированного проектирования". Правила стиля не следует рассматривать как "косметическое" средство. Разработка качественного ПО требует последовательности и внимания ко всем деталям, - к форме в той же степени, что и к содержанию. Задача повторного использования делает соблюдение этих правил еще более важным, поскольку предполагается, что исходные тексты ждет долгая жизнь, в течение которой многие люди будут в них разбираться и развивать их.
Следует правильно применять правила стиля с самого начала написания исходного текста класса. Так, никогда не следует начинать подпрограмму, не задав комментарий к заголовку. Это не займет много времени и это время нельзя считать потерянным. Фактически достигается существенная экономия времени при дальнейшей работе с этим классом его автором или другими программистами, возможно, через полчаса, скорее, через пять лет. Использование одинаковых отступов, грамотное написание комментариев и выбор идентификаторов, применение адекватных лексических соглашений (пробел перед каждой открывающей скобкой, но не после нее и т. д.) не слишком усложнят задачу, но сделают более совершенным результат многомесячного труда над громадой исходных текстов. Внимание к деталям, безусловно, не достаточное, но необходимое условие разработки качественного ПО.
Элементарные правила стиля совершенно понятны из приведенного примера класса. Поскольку целью настоящего раздела является изучение базовых механизмов объектной технологии, то детальному описанию правил стиля будет посвящена одна из последующих лекций ( курса "Основы объектно-ориентированного проектирования").
Другим аспектом класса POINT, требующим разъяснений, является присутствие в функциях rho и distance
продолжение следует...
Часть 1 7. Статические структуры: классы
Часть 2 Объектно-ориентированный стиль вычислений - 7. Статические структуры: классы
Часть 3 Программа main отсутствует - 7. Статические структуры: классы
Часть 4 Присваивание функции результата - 7. Статические структуры: классы
Исследование, описанное в статье про класс, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое класс, класс как структура данных и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Объектно-ориентированное программирование ООП
Комментарии
Оставить комментарий
Объектно-ориентированное программирование ООП
Термины: Объектно-ориентированное программирование ООП