Урок №13: «Знакомимся с объектно-ориентированным программированием»


Ну вот мы с вами добрались до того,  без чего язык C# теряет всяческий смысл. В этом уроке мы познакомимся с вами с объектами.

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

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

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

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

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

Бьярн Струпструп взял за основу эту парадигму и создал язык, который потом уже назвали  C++ (хотя сначал первые версии носили название С с классами).  Фактически, подход C++ характерен для всех объектно-ориентированных языков, особенно для потомков приплюснутого С.

Согласно ООП, мы теперь прежде чем что-то запрограммировать, должны продумать, какие в коде будут сущности, какими свойствами они обладают и как взаимодействовать между собой в коде. Фактически, спроектировав UML диаграмму (я покажу в других уроках, как ее делать в Visual Studio), вы выполните почти 70% всей работы. Написание кода по готовой UML значительно проще.

 

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

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

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

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

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

Проектирую класс, вам пригодятся правила русского языка. Часто объект – это существительное. Например, собака. Собака  бегает, лает и т.д. Это методы собаки или действия, а тут уже напрашивается сказуемое (глагол). Ну и свойства собаки типа веса, цвета, роста, породы уже будет просто определением. Часто это будет вам помогать.

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

<<Предыдущий урок                                                    Следующий урок >>

Яндекс.Метрика