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

Что такое классы в объектно-ориентированном программировании

Глубокое погружение в самую сложную и неинтуитивную область программирования.

В этом цикле статей мы говорим об объектно-ориентированном программировании — передовом и очень распространённом подходе к разработке. Это стоит знать всем, кто серьёзно относится к программированию и хочет зарабатывать в этой области.

Если не читали предыдущую статью, вот краткое содержание:

Одно из преимуществ ООП — не нужно много раз писать один и тот же код. Можно однажды придумать какую-то красивую штуку и потом заново её использовать буквально одной строкой. Для этого и нужны классы.

Что за классы

Вот одно из формальных определений класса: «Класс — это элемент ПО, описывающий абстрактный тип данных и его частичную или полную реализацию»

Если более по-русски, то класс — это шаблон кода, по которому создаётся какой-то объект. Это как рецепт приготовления блюда или инструкция по сборке мебели: сам по себе класс ничего не делает, но с его помощью можно создать новый объект и уже его использовать в работе.

Если пока непонятно, погружайтесь в пример:

Призовём на помощь силу примеров и поговорим про сотовые телефоны.

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

Но одного железа недостаточно — нужно соединить его между собой так, чтобы всё работало без сбоёв. Кроме этого, нужно предусмотреть, что происходит при нажатии на кнопки, что выводится на экран и как пользователь будет управлять этим телефоном.

Следующий этап — описать каждую деталь, из которой состоит телефон, каждую микросхему и плату, и объяснить, как детали работают друг с другом. Последний шаг — написать руководство пользователя, где будет полностью рассказано, что можно делать с телефоном, как запустить звонилку или отправить смс.

Мы только что сделали новый класс для телефона — полный набор нужных знаний, описаний, свойств и инструкций, который описывает нашу модель. Все эти инструкции и описания — это ещё не телефон, но из них этот телефон можно сделать.

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

Классы на практике

Все примеры дальше мы будем делать на Python, потому что это стильно, модно и молодёжно. А сам Python — очень объектно-ориентированный язык, почти всё в нём — это объекты. Вот и опробуем.

Допустим, мы пишем интернет-магазин с системой скидок. Нам нужно работать с пользователями — постоянными покупателями. Пользователь у нас будет объектом: у него будет имя, возраст и адрес доставки по умолчанию. Мы заведём класс, который поможет нам инициировать нового покупателя.

Здесь сказано: «Вот класс для покупателя. У него есть три свойства: имя, возраст и адрес». Теперь мы можем заводить новых покупателей одной строкой:

# Создаём первого покупателя

# Создаём второго покупателя

Что дальше

В следующем материале мы смоделируем реальную ситуацию: добавим программу лояльности, бонусные баллы и расскажем, как Python с этим справится. Чтобы было интереснее, будем писать код на двух языках сразу — Python и JavaScript.

Источник

Структурное против ООП программирование

Доброго времени суток. В этой статье я хочу показать не то, чем лучше структурное программирование или объектное, а то как нужно писать и там и там. И возможно это послужит выбором для тех, кто только хочет начать программировать и не знает какой язык выбрать и что может быть удобней. Я взял за пример языка C и JAVA.

Начну с первого, что приходит на ум. Это вроде не паттерн, но в ООП это приходится иногда использовать. Пишу сначала пример на java. Допустим нам нужно создать класс для двух видов реализации. К примеру нам нужно создать класс, чтобы подключаться к сайту по http и https. Это маленький пример, например этот же способ можно использовать, когда ты хочешь для android рисовать и в Opengl 2.0 es и Opengl 3.0 es. В этом случае будет больше кода и если сделать это таким способом, который приведу я, то вид кода будет нормальный. Но этот способ конечно же придумал не я, я его сам вычитал из книги когда-то. И так https и http. Чтобы это сделать, нужно создать интерфейс. И к этому интерфейсу присваивать нужный класс, в зависимости от типа протокола. Я точно не помню, но вроде я где-то читал, что ООП вправляет мозги. Что это позволяет писать грамотный красивый код. Возможно так. Но я почти в ООП не программирую и поэтому может это я так много кода пишу, а настоящий программист сделает более лаконичный код. Но вот хочу показать пример. Вот это интерфейс java.

Здесь мы объявляет две функции, одна для соединения, другая для получения URLConnection. Теперь два класса, чтобы это сработало.

Сколько кода нужно писать в connect и getConnection не важно. Для примера я выбрал мало кода, но его может быть много, если например Opengl es программировать. Но это удобно. Итак, осталась функция main.

На C можно воспользоваться curl и не писать много кода, но как бы этот пример можно было решить средствами C? В C есть указатели — это его сила. А вот пример на C — функция main.

Структура conn объявлена в другом файле.

Для init_http выделен целый файл с областью видимости, которые нужны для http.

Для init_https дополнительно нужен ssl. Поэтому в этом файле будут все те данные, которые нужны для этого подключения.

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

Источник

Класс (программирование)

Класс в программировании — набор методов и функций. Другие абстрактные типы данных — метаклассы, интерфейсы, структуры, перечисления — характеризуются какими-то своими, другими особенностями. Наряду с понятием «объекта» класс является ключевым понятием в ООП (хотя существуют и бесклассовые объектно-ориентированные языки, например, JavaScript; подробнее смотрите Прототипное программирование). Суть отличия классов от других абстрактных типов данных состоит в том, что при задании типа данных класс определяет одновременно и интерфейс, и реализацию для всех своих экземпляров, а вызов метода-конструктора обязателен. Точный смысл этой фразы будет раскрыт ниже.

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

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

Везде далее слова «класс», «объект», «интерфейс» и «структура» будут употребляться в своих специальных значениях, заданных в рамках ООП.

Содержание

Классы и объекты, понятие экземпляра класса, понятие членов класса

В объектно-ориентированной программе с применением классов каждый объект является «экземпляром» некоторого конкретного класса, и других объектов не предусмотрено. То есть «экземпляр класса» в данном случае означает не «пример некоторого класса» или «отдельно взятый класс», а «объект, типом которого является какой-то класс». При этом в разных языках программирования допускается либо не допускается существование еще каких-то типов данных, экземпляры которых не являются объектами (то есть язык определяет, являются ли объектами такие вещи, как числа, массивы и указатели, или не являются, и, соответственно, есть ли такие классы как «число», «массив» или «указатель», экземплярами которых были бы каждое конкретное число, массив или указатель).

Например, абстрактный тип данных «строка текста» может быть оформлен в виде класса, и тогда все строки текста в программе будут являться объектами — экземплярами класса «строка текста».

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

Как и структуры, классы могут задавать поля — то есть переменные, принадлежащие либо непосредственно самому классу (статические), либо экземплярам класса (обычные). Статические поля существуют в одном экземпляре на всю программу (или, в более сложном варианте, — в одном экземпляре на процесс или на поток/нить). Обычные поля создаются по одной копии для каждого конкретного объекта — экземпляра класса. Например, общее количество строк текста, созданных в программе за время её работы, будет являться статическим полем класса «строка текста». А конкретный массив символов строки будет являться обычным полем экземпляра класса «строка текста», так же как переменная «фамилия», имеющая тип «строка текста», будет являться обычным полем каждого конкретного экземпляра класса «человек».

В ООП при использовании классов весь исполняемый код программы (алгоритмы) будет оформляться в виде так называемых «методов», «функций» или «процедур», что соответствует обычному структурному программированию, однако теперь они могут (а во многих языках обязаны) принадлежать тому или иному классу. Например, по возможности, класс «строка текста» будет содержать все основные методы/функции/процедуры, предназначенные для работы со строкой текста, такие как поиск в строке, вырезание части строки и т. д.

Как и поля, код в виде методов/функций/процедур, принадлежащих классу, может быть отнесен либо к самому классу, либо к экземплярам класса. Метод, принадлежащий классу и соотнесенный с классом (статический метод) может быть вызван сам по себе и имеет доступ к статическим переменным класса. Метод, соотнесенный с экземпляром класса (обычный метод), может быть вызван только у самого объекта, и имеет доступ как к статическим полям класса, так и к обычным полям конкретного объекта (при вызове этот объект передастся скрытым параметром метода). Например, общее количество созданных строк можно узнать из любого места программы, но длину конкретной строки можно узнать только указав, тем или иным образом, длину какой строки будем мерить.

Сам класс не является объектом, однако, в зависимости от языка программирования и платформы, программисту могут быть доступны те или иные объекты, позволяющие получить информацию о классе — название, список членов, объем памяти, занимаемой классом или отдельным экземпляром. Например, может существовать специальный класс «тип данных», экземпляры которого описывают тот или иной конкретный класс, существующий в программе.

Интерфейс и реализация, наследование реализации

В программировании существует понятие программного интерфейса, означающего перечень возможных вычислений, которые может выполнить та или иная часть программы, включая описание того, какие аргументы и в каком порядке требуется передавать на вход алгоритмам из этого перечня, а также что и в каком виде они будут возвращать. Абстрактный тип данных интерфейс придуман для формализованного описания такого перечня. Сами алгоритмы, то есть действительный программный код, который будет выполнять все эти вычисления, интерфейсом не задаётся, программируется отдельно и называется реализацией интерфейса.

Программные интерфейсы, а также классы, могут расширяться путем наследования, которое является одним из важных средств повторного использования готового кода в ООП. Наследованный класс или интерфейс будет содержать в себе всё, что указано для всех его родительских классов (в зависимости от языка программирования и платформы, их может быть от нуля до бесконечности). Например, можно создать свой вариант текстовой строки путем наследования класса «моя строка текста» от уже существующего класса «строка текста», при этом предполагается, что программисту не придется заново переписывать алгоритмы поиска и прочее, так как они автоматически будут унаследованы от готового класса, и любой экземпляр класса «моя строка текста» может быть передан не только в готовые методы родительского класса «строка текста» для проведения нужных вычислений, но и вообще в любой алгоритм, способный работать с объектами типа «строка текста», так как экземпляры обоих классов совместимы по программным интерфейсам.

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

Состояние объекта, понятие областей доступа, конструкторы

Одной из проблем структурного программирования, с которой борется ООП, является проблема поддержания правильного значения переменных программы. Часто разные переменные программы хранят логически связанные значения, и за поддержание этой логической связности несет ответственность программист, то есть автоматически связность не поддерживается. Примером могут служить флажки «уволен» и «ожидает премии по итогам года», когда по правилам отдела кадров человек может быть одновременно не уволенным и не ожидающим премии, не уволенным и ожидающим премии, уволенным и не ожидающим премии, но не может быть одновременно и уволенным, и ожидающим премии. То есть любая часть программы, которая проставляет флажок «уволен», всегда должна снимать флажок «ожидает премии по итогам года».

Хороший способ решить эту проблему — объявить флажок «уволен» недоступным к изменению для всех участков программы, кроме одного специально оговоренного. В этом специально оговоренном участке всё будет написано один раз и правильно, а все остальные должны будут обращаться к этому участку всегда, когда они хотят установить или снять флажок «уволен».

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

Почти каждому члену класса можно установить модификатор доступа (за исключением статических конструкторов и некоторых других вещей). В большинстве объектно-ориентированных языков программирования поддерживаются следующие модификаторы доступа:

Проблема поддержания правильного состояния переменных актуальна и для самого первого момента выставления начальных значений. Для этого в классах предусмотрены специальные методы/функции, называемые конструкторами. Ни один объект (экземпляр класса) не может быть создан иначе, как путем вызова на исполнение кода конструктора, который вернет вызывающей стороне созданный и правильно заполненный экземпляр класса. Во многих языках программирования тип данных «структура», как и класс, может содержать переменные и методы, но экземпляры структур, оставаясь просто размеченным участком оперативной памяти, могут создаваться в обход конструкторов, что запрещено для экземпляров классов (за исключением специальных исключительных методов обхода всех подобных правил ООП, предусмотренных в некоторых языках и платформах). В этом проявляется отличие классов от других типов данных — вызов конструктора обязателен.

Практический подход

В современных объектно-ориентированных языках программирования (в том числе в php, Java, C++, Oberon, Python, Ruby, Smalltalk, Object Pascal) создание класса сводится к написанию некоторой структуры, содержащей набор полей и методов (среди последних особую роль играют конструкторы, деструкторы, финализаторы). Практически класс может пониматься как некий шаблон, по которому создаются объекты — экземпляры данного класса. Все экземпляры одного класса созданы по одному шаблону, поэтому имеют один и тот же набор полей и методов.

Отношения между классами

Виды классов

Область видимости

Область видимости членов класса (то есть область кода, из которой к ним можно обращаться по неквалифицированному имени — без указания имени класса или объекта) не зависит от их области доступа, и всегда совпадает с кодом методов класса.

Область видимости самого класса по-разному определяется в разных языках программирования. В одних языках (таких как Delphi) все классы имеют глобальную видимость (с учётом видимости модуля), в других (таких как Java) область видимости класса связана с содержащей его единицей компиляции (в Java — с пакетом), в третьих (таких как C++ и C#) область видимости класса определяется пространствами имён (namespaces), которые задаются программистом явно и могут совпадать или не совпадать с единицами компиляции.

Классы в языке Object Pascal (среда Delphi)

На языке Delphi класс описывается следующим образом:

Источник

Объектно-ориентированное программирование: на пальцах

Статья не мальчика, но мужа.

Настало время серьёзных тем: сегодня расскажем про объектно-ориентированное программирование, или ООП. Это тема для продвинутого уровня разработки, и мы хотим, чтобы вы его постигли.

Из этого термина можно сделать вывод, что ООП — это такой подход к программированию, где на первом месте стоят объекты. На самом деле там всё немного сложнее, но мы до этого ещё доберёмся. Для начала поговорим про ООП вообще и разберём, с чего оно начинается.

Обычное программирование (процедурное)

Чаще всего под обычным понимают процедурное программирование, в основе которого — процедуры и функции. Функция — это мини-программа, которая получает на вход какие-то данные, что-то делает внутри себя и может отдавать какие-то данные в результате вычислений. Представьте, что это такой конвейер, который упакован в коробочку.

можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть картинку можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Картинка про можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный

Например, в интернет-магазине может быть функция «Проверить email». Она получает на вход какой-то текст, сопоставляет со своими правилами и выдаёт ответ: это правильный электронный адрес или нет. Если правильный, то true, если нет — то false.

можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть картинку можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Картинка про можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный

Функции полезны, когда нужно упаковать много команд в одну. Например, проверка электронного адреса может состоять из одной проверки на регулярные выражения, а может содержать множество команд: запросы в словари, проверку по базам спамеров и даже сопоставление с уже известными электронными адресами. В функцию можно упаковать любой комбайн из действий и потом просто вызывать их все одним движением.

Что не так с процедурным программированием

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

Например, вы пишете функцию «Зарегистрировать пользователя интернет-магазина». Внутри неё вам нужно проверить его электронный адрес. Вы вызываете функцию «Проверить email» внутри функции «Зарегистрировать пользователя», и в зависимости от ответа функции вы либо регистрируете пользователя, либо выводите ошибку. И у вас эта функция встречается ещё в десяти местах. Функции как бы переплетены.

можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть картинку можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Картинка про можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный

Тут приходит продакт-менеджер и говорит: «Хочу, чтобы пользователь точно знал, в чём ошибка при вводе электронного адреса». Теперь вам нужно научить функцию выдавать не просто true — false, а ещё и код ошибки: например, если в адресе опечатка, то код 01, если адрес спамерский — код 02 и так далее. Это несложно реализовать.

Вы залезаете внутрь этой функции и меняете её поведение: теперь она вместо true — false выдаёт код ошибки, а если ошибки нет — пишет «ОК».

И тут ваш код ломается: все десять мест, которые ожидали от проверяльщика true или false, теперь получают «ОК» и из-за этого ломаются.

можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть картинку можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Картинка про можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный

Задача, конечно, решаемая за час-другой.

Но теперь представьте, что у вас этих функций — сотни. И изменений в них нужно делать десятки в день. И каждое изменение, как правило, заставляет функции вести себя более сложным образом и выдавать более сложный результат. И каждое изменение в одном месте ломает три других места. В итоге у вас будут нарождаться десятки клонированных функций, в которых вы сначала будете разбираться, а потом уже нет.

Это называется спагетти-код, и для борьбы с ним как раз придумали объектно-ориентированное программирование.

можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть картинку можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Картинка про можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный

Объектно-ориентированное программирование

Основная задача ООП — сделать сложный код проще. Для этого программу разбивают на независимые блоки, которые мы называем объектами.

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

можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть картинку можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Картинка про можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный

Программисты договорились, что данные внутри объекта будут называться свойствами, а функции — методами. Но это просто слова, по сути это те же переменные и функции.

Объект можно представить как независимый электроприбор у вас на кухне. Чайник кипятит воду, плита греет, блендер взбивает, мясорубка делает фарш. Внутри каждого устройства куча всего: моторы, контроллеры, кнопки, пружины, предохранители — но вы о них не думаете. Вы нажимаете кнопки на панели каждого прибора, и он делает то, что от него ожидается. И благодаря совместной работе этих приборов у вас получается ужин.

Объекты характеризуются четырьмя словами: инкапсуляция, абстракция, наследование и полиморфизм. Если интересно, что это такое, приглашаем в кат:

Инкапсуляция — объект независим: каждый объект устроен так, что нужные для него данные живут внутри этого объекта, а не где-то снаружи в программе. Например, если у меня есть объект «Пользователь», то у меня в нём будут все данные о пользователе: и имя, и адрес, и всё остальное. И в нём же будут методы «Проверить адрес» или «Подписать на рассылку».

Абстракция — у объекта есть «интерфейс»: у объекта есть методы и свойства, к которым мы можем обратиться извне этого объекта. Так же, как мы можем нажать кнопку на блендере. У блендера есть много всего внутри, что заставляет его работать, но на главной панели есть только кнопка. Вот эта кнопка и есть абстрактный интерфейс.

Например, над магазином работают два программиста: один пишет модуль заказа, а второй — модуль доставки. У первого в объекте «заказ» есть метод «отменить». И вот второму нужно из-за доставки отменить заказ. И он спокойно пишет: «заказ.отменить()». Ему неважно, как другой программист будет реализовывать отмену: какие он отправит письма, что запишет в базу данных, какие выведет предупреждения.

можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть картинку можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Картинка про можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный

Наследование — способность к копированию. ООП позволяет создавать много объектов по образу и подобию другого объекта. Это позволяет не копипастить код по двести раз, а один раз нормально написать и потом много раз использовать.

Например, у вас может быть некий идеальный объект «Пользователь»: в нём вы прописываете всё, что может происходить с пользователем. У вас могут быть свойства: имя, возраст, адрес, номер карты. И могут быть методы «Дать скидку», «Проверить заказ», «Найти заказы», «Позвонить».

На основе этого идеального пользователя вы можете создать реального «Покупателя Ивана». У него при создании будут все свойства и методы, которые вы задали у идеального покупателя, плюс могут быть какие-то свои, если захотите.

Идеальные объекты программисты называют классами.

Полиморфизм — единый язык общения. В ООП важно, чтобы все объекты общались друг с другом на понятном им языке. И если у разных объектов есть метод «Удалить», то он должен делать именно это и писаться везде одинаково. Нельзя, чтобы у одного объекта это было «Удалить», а у другого «Стереть».

При этом внутри объекта методы могут быть реализованы по-разному. Например, удалить товар — это выдать предупреждение, а потом пометить товар в базе данных как удалённый. А удалить пользователя — это отменить его покупки, отписать от рассылки и заархивировать историю его покупок. События разные, но для программиста это неважно. У него просто есть метод «Удалить()», и он ему доверяет.

можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Смотреть картинку можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Картинка про можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный. Фото можно ли сказать что внешний вид кода класса в объектно ориентированном коде похож на структурный

Такой подход позволяет программировать каждый модуль независимо от остальных. Главное — заранее продумать, как модули будут общаться друг с другом и по каким правилам. При таком подходе вы можете улучшить работу одного модуля, не затрагивая остальные — для всей программы неважно, что внутри каждого блока, если правила работы с ним остались прежними.

Плюсы и минусы ООП

У объектно-ориентированного программирования много плюсов, и именно поэтому этот подход использует большинство современных программистов.

А теперь про минусы:

Что дальше

Впереди нас ждёт разговор о классах, объектах и всём остальном важном в ООП. Крепитесь, будет интересно!

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *