11 марта 2010 в 11:37

ООП с примерами (часть 1)

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

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

Первая часть, представленная ниже, посвящена классам, объектам и интерфейсам.
Вторая часть иллюстрирует инкапсуляцию, полиморфизм и наследование



Основные понятия ООП


Класс

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

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

Класс – это способ описания сущности, определяющий состояние и поведение, зависящее от этого состояния, а также правила для взаимодействия с данной сущностью (контракт).

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

С точки зрения структуры программы, класс является сложным типом данных.

В нашем случае, класс будет отображать сущность – автомобиль. Атрибутами класса будут являться двигатель, подвеска, кузов, четыре колеса и т.д. Методами класса будет «открыть дверь», «нажать на педаль газа», а также «закачать порцию бензина из бензобака в двигатель». Первые два метода доступны для выполнения другим классам (в частности, классу «Водитель»). Последний описывает взаимодействия внутри класса и не доступен пользователю.

В дальнейшем, несмотря на то, что слово «пользователь» ассоциируется с пасьянсом «Косынка» и «Microsoft Word», мы будем называть пользователями тех программистов, которые используют ваш класс, включая вас самих. Человека, который является автором класса, мы будем называть разработчиком.

Объект

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

Объект (экземпляр) – это отдельный представитель класса, имеющий конкретное состояние и поведение, полностью определяемое классом.

Говоря простым языком, объект имеет конкретные значения атрибутов и методы, работающие с этими значениями на основе правил, заданных в классе. В данном примере, если класс – это некоторый абстрактный автомобиль из «мира идей», то объект – это конкретный автомобиль, стоящий у вас под окнами.

Интерфейс

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

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

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

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

Примером простого интерфейса может служить машина с коробкой-автоматом. Освоить её управление очень быстро сможет любая блондинка, окончившая двухнедельные курсы вождения. С другой стороны, чтобы освоить управление современным пассажирским самолётом, необходимо несколько месяцев, а то и лет упорных тренировок. Не хотел бы я находиться на борту Боинга, которым управляет человек, имеющий двухнедельный лётный стаж. С другой стороны, вы никогда не заставите автомобиль подняться в воздух и перелететь из Москвы в Вашингтон.
Михаил Пайсон @Tomcat
карма
187,0
рейтинг 0,0
Разработкой руковожу
Самое читаемое Разное

Комментарии (67)

  • +3
    А где картинки? Один текст =(
    • +7
      Включите воображение!)
    • 0
      Спасибо :). Честно говоря, тоже вопрос возник сразу же… Добавил кавычки в заголовок.
  • +6
    Вопрос напрашивается сам собой: «А где же картинки?»
  • –7
    Хочется воскликнуть: «Наебалово!»
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Всё, уважаемые господа и дамы. Критику понял, пост переименовал :)
    • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    на самом деле на живых примерах нихрена не понятно :) (ну то есть сужу по своей практики обучения) пока не начнешь разбирать практические примеры, вообще не понятно что такое ООП…
    • 0
      Полностью согласен. Есть ещё практические занятия, на которых мы пишем код, разбираем на примерах что такое, например, полиморфизм, как им пользоваться, зачем он нужен (типичный пример — какая-нибудь абстрактная фабрика).

      Тут большие проблемы с теоретическим пониманием того, что же всё таки такое класс. К сожалению, в большинстве источников написано, что это «совокупность полей и методов для работы с ними» — но, на самом-то деле это ещё не класс… Это всё равно как описать человека как «совокупность конечностей и туловища» или «совокупность тела и разума для управления им»…
      • 0
        Ну зачем же сразу в крайности, живые существа, тем более человек — это очень сложные классы, и чтобы их в точности описать сегодняшней науки и мощностей не хватит. Простыми словами — класс это образ сущности (объекта) имеющий определенные свойства (поля) и функции (методы) и являющийся элементом системы (программы). Кстати, если так рассуждать, то класс человека, да и всех живых существ, в их ДНК :)
        • +1
          В том-то и дело, что в классе, по-сути, главное — именно функциональность, т.е. то, что методы и данные увязаны в одно целое и методы производят операции над данными. Важно не то, что класс имеет методы, а то, что эти методы выполняют определённые действия над данными класса (и не только).

          А по поводу ДНК — не могу согласиться. ДНК никоим образом не описывает поведение человека. Если уж на то пошло, то ДНК — скорее абстрактная фабрика, которая обеспечивает создание экземпляров разных классов, с одинаковым интерфейсом :).
          • 0
            С первым высказыванием согласен, а вот со вторым поспорю :)
            ДНК описывает все изначальные параметры человека и весь его функционал, если не ДНК, то что? Поведение уже относится к другой ипостаси, мозгу, самообучающейся нейронной сети (изначальные параметры которой кстати тоже диктуются ДНК). Из этого можно сделать (а можно и не сделать, все ведь относительно ;) ), что ДНК человека это самый настоящий естественный класс, своеобразный и очень сложный, а человек — экземпляр этого класса. Здесь еще многое можно сказать о наследовании, инкапсуляции о социальной надстройке, которая в совокупности образует новый, более глобальный класс (общество), элементами которого являются люди (а где тогда ДНК общества? может в книгах, знаниях, обычаях, а может и нет...).
    • –1
      мы как раз сегодня изучали классы.

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

    Так что ИМХО, просто теории и практики мало. Нужно сначала брать уже готовые программы на ООП, и разбирать их, причём не на лекциях на доске, а в качестве практических. Или первые лабораторные делать «изменить некоторые методы в этом классе так-то и так-то», а уж потом самостоятельное составление программ на ООП
    • 0
      Вообще, цель курса не обучить ООП, а показать, что такое паттерны проектирования. Подразумевается, что к этому моменту студент ООП уже знает и это как бы повторение. Т.е. они уже писали и на C++ и на Java, но понимания, что такое public class Foo на самом деле, у них нет. Большинство, к сожалению, считает, что это магическое заклинание.
      • 0
        вспоминается цитата с баша:
        Волею судеб начал не так давно программировать на C#. И все бы ничего, но, по непонятной причине, меня начало переть с довольно часто встречающейся в нем конструкции — public static void
        Долго думал, с чего бы это. И через неделю меня осенило. Ведь это же по ударениям — один в один всем знакомое с детства КРИБЛЕ КРАБЛЕ БУМС!


        А если серьезно, то имхо, рассказывать ООП с нуля студентам нужно в тот момент когда они еще ничего не знают ни про C# ни про Java, так сказать, сферическое ООП в вакууме.
        • 0
          Боюсь, в этом случае они абсолютно ничего не поймут. Главное — у них не будет мотивации понимать. Как, по большому счёту, нет мотивации разбираться с каким нибудь термехом или урматами у большинства студентов направления computer since.

          Я, конечно, не говорю про отдельные исключения. Мне, например, термех нравился ;).
          • +1
            Я конечно еще не преподаю, зато многие нюансы преподавателей со своей кафедры замечал. Например, мне на первом курсе дали задание написать клиент-серверный чат, многопоточный, по протоколу TCP, на C#.

            Представьте, первый курс, а тут такое. А на кону зачет. Меня «заинтересовали», с тех пор я программирую на C# (уже 2.5 года, получается).

            Бывают студенты, которые не понимают потому что не хотят погружаться в материал.

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

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

            Главное не вдаваться в крайности, то есть можно зверствовать ради того, чтобы всех вынести, а можно поставить требования чуть выше среднего и помогать студентам взять эту планку, быть открытым к вопросам и разбираться вместе с теми, кто хочет, но не понимает.
            • 0
              Вот с этим согласен на 100%. По большому счёту, в рамках курса по архитектуре именно «практика — критерий истины».

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

              И, что самое удивительное, с такой достаточно сложной тематикой и архитектурой справляются практически все.
              • 0
                Значит вы на верном пути.

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

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

                Может быть вырастет поколение гениальных программистов, а Вы к этому еще и руку приложите )
                • 0
                  Не думаю, что имеет смысл требовать чего-то большего. Если обучение комфортно (особенно на пятом курсе), то знания усваиваются лучше. Тем более, половине из них ещё диплом защищать — лишняя нагрузка ни к чему.

                  А про воспитание хороших программистов — исключительно на производстве и, желательно, у меня в команде. Я же тоже в вузе не только для развлечения работаю ;). Head hunting в таком виде максимально эффективен.
              • 0
                поделюсь своим опытом.
                Мой преподаватель, объяснявший нам что такое паттерны и с чем их едят (я весь курс слушал с горящими глазами) задание придумал следующее (он его еще лет 5 назад наверное придумал, но выглядело это так, как будто только что): построенный на ООП анализатор алгебраических выражений с возможностью их вычислять. Для хранения дерева выражения используется композит (выражение, от которого наследуются константа, переменная, сложное выражение), для их строительства — билдер (по одному на каждый класс), потом для того, чтобы переменные хранились только один раз — диспетчер какой-нибудь, дальше семестр заканчивался.
                Еще был интересный проект для диплома — графический редактор блок-схем: шаблоны фасад, наблюдатель, композит, медиатор, билдер конечно же, может еще парочку. Но это сложнее, чем первый. Надеюсь, поможет.
                А вообще я паттерны люблю, пишите еще :)
  • +5
    Когда мы проходили ООП, нам тоже втюхивали примеры с автомобильчиками. И знаете, по-моему это достаточно неудачная идея. По-крайней мере могу сказать что тогда это не помогло осмыслить ООП ни одному человеку.
    • +2
      Абсолютно согласен. Пример с автомобилем ни в какие ворота не лезет. На мой взгляд он только вносит путаницу, проще понять на примерах про объект и методы.
      • 0
        Вы можете порекомендовать, в каком изложении ООП было бы наиболее понятным для Вас лично? Если не трудно, привести «пример про объект и методы»? Был бы очень благодарен.
        • +1
          В контексте популярной ныне архитектуры MVC можно рассказать про Модель. Причем, не только про то, что есть некие данные 'title', 'speed' и методы 'save'… А рассказать на примере наследования, как все удобно и просто работает. (Вот описание создания своей модели путем наследования на Django).

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

          А то с примерами на автомобилях у меня было представления, что ООП годится, только чтобы игры писать.
        • 0
          А мне про чайник нравиться пример.
          Особенно с абстрактным чайником и наследованием его в газовый и электрический.
        • +1
          Помню читал когда-то Гради Буча, там были примеры с растениями. На этих примерах объяснялось наследование, как наследуются общие свойства и характеристики, поведение.

          Но, этот пример также можно использовать для понятия Класс и Объект: например, есть класс «Цветок» который имеет свойство цвет, рост и др. Объект, допустим, «роза» красного цвета и определенным размером куста.

          Кстати, в той книге Буча, было достаточно много примеров, которые вам могут пригодиться. Название, возможно, знакомо: Объектно-ориентированный анализ и проектирование.
    • 0
      Нас учили на примере геометрических фигур, я тогда тоже ничего не понял… хотя щас кажется, что это довольно понятное объяснение. А вот автомобиль мне тоже не нравится, лучше бы объяснять ооп на примере чего-то не представляющего настолько единый объект, а на том где очевидно можно выделить составляющие. Нет, конечно и у автомобиля тоже можно выделить, но он хочет восприниматься сразу как единая сущность и это может сбить с толку.
  • +2
    А мне понравились аналогии, весьма доступно и понятно. Продолжайте, пожалуйста!
  • +1
    я вот «пишу на 1с» там никаких классов нет. ну как минимум название не используется. С автомобилем худо-бедно ассоциация понятна. но как он выглядит… не представляю. Воображение рисует функцию с параметрами, как наиболее близкий аналог… старательно перечитал дважды… если цель, чтобы точно поняли постарайтесь картинку какую-то предъявить… и может пример какой-то. хотя не представляю как выглядит пример. Говорю, как человек не знакомый с ОПП: что-то понятно, но не окончательно.
    • 0
      Спасибо, буду думать, как это лучше описать.

      Но, исключительно для оправдания: на самом деле, целевая аудитория ООП в том или ином виде знает. Поэтому данный текст рассчитан скорее на «освежение» этих знаний и, я надеюсь, позволяет взглянуть на это с другого ракурса, понять, что ООП — это не обязательно «способ писать компьютерную программу», но и, в некотором роде, встречается в реальном мире.
      • +6
        У нас на курсе были те же проблемы.
        Никто не понимал, что такое класс, что такое объект, а главное — «в чем разница». Я ООП очень люблю, я его везде «вижу». Когда-то для себя в качестве примера провела аналогию не с автомобилем (в котором большинство студентов не ездит), а с лифтом. Класс — это проект лифта. Именно проект. Ну, т.е., то, каким он будет. У него есть высота, ширина, скорость — это свойства. Он умеет ездить — вверх/вниз, это методы. То, что стоит у нас в домах — это экземпляры класса «Лифт», у которых есть свой номер (у каждого). А интерфейс — это кнопки. По проекту мы можем наштамповать этих лифтов столько, сколько угодно. Можем менять им в процессе цвет двери, например (паблик чтение/запись свойства), но не можем менять скорость, которая постоянна (паблик рид свойство). У него есть куча внутренних свойств, которые нам неведомы, но благодаря им лифт работает.
        Ну, вот у меня какая-то такая когда-то аналогия возникла. Конечно, не так красиво, как с автомобилем. И не факт, что понятнее. Но поделиться… :)
        • 0
          по-моему классно, я тоже на примере лифта объяснял :)
        • 0
          Кстати да, с лифтом более понятно )
      • 0
        не-не оправдание не нужно. ваши то знают, это я пока далек, надо будет-придется брать какую-то книжку и разбираться. пока ещё нет такой необходимости.
        а ниже про лифт тоже в принципе понятный пример)
  • 0
    Уверен, что главной проблемой при изучении ООП является терминология. Когда я впервые услышал «полиморфизм», «инкапсуляция», у меня на долгое время пропала программистская потенция. Считаю, что первым делом нужно вообще запретить пользоваться терминологией ООП и вводить её только после того, как окончательно усвоена суть.
    • 0
      «инкапсуляция» особенно сшибает с ног :)
      • +1
        Напишу ещё попозже и про инкапсуляцию…

        А в двух словах — всё предельно просто in-capsulo, «в капсуле». Внутренняя логика скрыта в классе «как в капсуле» и не видна снаружи. Виден только интерфейс, т.е. набор методов, который действительно хотели показать.
  • 0
    Еще смущает что человеку совсем далекому от ООП вы сразу же даете кучу терминов — «С точки зрения программирования класс можно рассматривать как набор данных (полей, атрибутов, членов класса) и функций для работы с ними (методов).

    С точки зрения структуры программы, класс является сложным типом данных.» каких полей каких атрибутов… сложным типом относительно чего!?
    а так вполне:-)
    • 0
      Спасибо.
      Очень надеюсь, что те будущие программисты, которым я курс читаю, не совсем далеки от ООП (хотя, глядя на них, иногда сомневаюсь:) ).

      А про сложный тип — относительно «простого типа данных» естественно :).
      • 0
        Ну вот возьмем к примеру меня:)как то так сложилось что я всю сознательную жизнь в кручусь в IT сфере, за всю жизнь у меня не получилось научится программировать — по разным причинам, то не было достойного учителя то скушные маны и учебники нагоняли тоску то не было интересных задач. Я уже заканчиваю универ, в нем преподавали С++ на первом курсе, оттуда я не помню ничего — не заинтересовали, сейчас я осознаю что пора менять ситуацию, начинаю интересоваться… вот ваша статья надеюсь будет стартом, она уже в закладках.
        ЗЫ, я учусь по специальности «Информационные системы и технологии» и надеюсь в этой сфере неплохой специалист:)
        • 0
          Ну так вот, о чем это я… а — жду продолжения:-)
          • 0
            Оно уже есть. Смотрите ссылку в шапке поста.
  • +1
    Вы не поверите, как же я долго вбивал в себе в голову суть ООП. Я до сих пор, как это видно сейчас, где только не нахожу альтернативные статьи с разьяснениями такого подхода к программированию с удовольствием читаю и заново переделываю свои шаблоны. Хоть, ооп для меня уже давно понятно, ясно и используется. Очень наглядный пример, спасибо — это интересно :)
  • 0
    Класс – это способ описания сущности, определяющий состояние и поведение, зависящее от этого состояния, а также правила для взаимодействия с данной сущностью (контракт).


    Какой ужасный, ужасный канцелярит. Подобные описания хороши в учебнике, но никак не в курсе популяризации.

    А пример с машинками он не просто вреден, он архивреден!
    Хоть он и канониченЪ, но он на корню губит идею сложных объектов и агрегации. Человек, который привык работать с «машинками» очень долго доходит до понимания того, что иногда не объект «дверь» агрегирует объект «замочная скважина», а наоборот.
    • 0
      иногда не объект «дверь» агрегирует объект «замочная скважина», а наоборот.

      Прям как в книжках про волшебников. Вставляешь ключ и появляется дверь :)
      • 0
        Примитивный пример: есть сущности «статья» и «категория», статьи принадлежат категориям.

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

        Но некоторые могут не понять, что у объекта «статья» может быть свойство — объект «родительская категория», т.к. в физическом мире «машинок» бОльший объект не может лежать внутри меньшего.
        • 0
          Хм… Пример «родительской категории» в машине является завод изготовитель. Или я что-то недопонимаю в ваших объяснениях.
          • +1
            Абсолютно верно, но неочевидно для начинающих :)

            Заметьте, в качестве примеров методов и свойств машины в 95% выступают такие методы и свойства, как: «номер машины», «завести», «залить бензин», т.е. некие «физические» объекты, которые находятся внутри машины.

            А потом новички с удивлением обнаруживают, что в машине находятся не только сиденье с багажником, но и завод, в котором в свою очередь находится город. И вообще, машина нужна исключительно для того, чтобы предоставить интерфейс для доступа к городу :)))
            • 0
              А вот с последнее ваше дополнение, по-моему, автору топика стоит добавить в свои лекции, для более лучшего понимания темы :)
              • +3
                Спасибо :)
                На самом деле, ООП — это именно та вещь, которая представляет собой типичный случай зависимости от масштаба.
                Чем сложнее проект, тем большее количество паттернов вовлекается в работу, тем не-нативнее и не-«физичнее» становится система, и наступает тот момент, когда Алиса открывает дверь Кроликом, который агрегирует Льюиса Кэролла, у которого в кармане лежит ключ.
            • +1
              Да, спасибо. Обязательно добавлю про завод. Действительно, наглядно и важно.
  • 0
    Пример класса — целое число.
    Экземпляр класса — 1, 8, 42, -16.

    Вообще, даже на самом старте не было сложностей с разделением класса и объекта.
  • 0
    Если уж давать ООП для тех, кто хоть один язык худо-бедно знает, то начинать надо со смолтолковской объектной модели, а потом уже показывать, почему в традиционных языках она превратилась в структуры+интерфейсы.
  • 0
    Давать определение интерфейса как публичные методы класса не совсем верно.
    Последовательность по идее должна быть такой — интерфейс, реализация интерфейса (конкретный класс), объект (экземпляр класса)
  • +1
    Спасибо! Очень нужная тема, как раз пробую вникнуть в ООП, но после си плохо все идет((
    Ждем продолжения :)
  • –1
    c такими определениями класса и интерфейса, немудрено, что «большинство испытывают затруднения даже с пониманием основных терминов ООП»
    • 0
      Всё таки, люди — математики-программисты, определения приходится давать строгие. На лекции пытаюсь прояснить суть этого набора слов. Насколько вижу — удаётся.
  • +1
    Я в своих лекциях обычно начинаю даже не с классов и объектов — а со способов декомпозиции — чтобы было понятно, зачем вообще нужно делить систему на классы. Рассказываю на примере чайников. :)

    Еще важно показать, что поведение объекта зависит от его состояния и это одна из фишек, которая отличает его от просто структуры с набором функций. В примере с автомобилем — нажатие на педаль газа будет работать по-разному в зависимости от состояния автомобиля. Если автомобиль не заведен — то педаль газа ничего не будет делать. Если завести автомобиль, то он перейдет в состояние заведен и тогда нажатие педали газа будет действовать на него по-другому.
    Состояние объекта может меняться благодаря внешнему воздействию (например, переключили передачу) или внутренним действиям (бензин кончился).
    • 0
      Зависимость поведения от состояния — это частный случай. Существуют объекты сразу готовые для использования после создания.
      В примере с автомобилем — есть функция интерфейса «Завести автомобиль» которую необходимо вызвать перед использованием других функций(не всех) автомобиля. Но вполне возможен гипотетический вариант когда при нажатии на педаль газа автомобиль сам заводится и начинает движение.
      • +1
        Разумеется, бывают методы, которые не зависят от состояния, но тогда они мало отличаются от обычных функций и их, кстати, часто даже делают статическими в целях оптимизации.

        В данном случае объект тоже готов к использованию после создания. Завести автомобиль в данном случае — не аналог конструктора или Init, а полноценное действие. Вы ведь можете завести автомобиль, поездить, а потом заглушить мотор переводя его опять в начальное состояние.

        Я обычно привожу пример с автоматом. Есть режим переключения стрельбы — одиночные и очередь. В зависимости от текущего режима и кол-ва патронов, один и тот же метод Fire работает по-разному (поведение зависит от состояния). По мере стрельбы кол-во патронов уменьшается (состояние изменяется).
        Без ООП мы бы вызывали что-то вроде Fire(ammoCount, burstMode), а в ООП вся информация хранится в объекте и мы вызываем просто Fire().

        Требование инициализации для работы некоторых методов действительно не очень хорошее решение и лучше выполнять инициализацию по мере необходимости (как, например, в Singleton и LazyLoad).
  • 0
    "… приборная панель автомобиля, которая позволяет вызвать такие методы, как увеличение скорости, торможение, поворот, переключение передач, включение фар..."

    А как приборная панель может влиять на увеличение скорости и торможение? Я думал на педальки давить нужно :)
    • 0
      Автомобиль в примере наверное оборудован круиз-контролем :) Хотя, там в большинстве случаев тоже педальками нужно пользоваться)
    • 0
      Ну, я педали тоже к приборной панели отношу. Если так проще, можно считать, что это автомобиль с ручным управлением, для инвалидов, например.
  • +2
    прежде чем учить ООП, нужно понять, что ООП бывает и без слова Class. Советую объяснять примеры с людьми и их взаимоотношениями. вместо машины направьте взор на самую симпатичную девушку на потоке, на её примере объясняйте объекты, атрибуты, методы взаимодействия с внешним миром.
    будет куча споров. вам не нужно объяснять что такое класс и интерфейс, заставьте их вспомнить об ооп из жизни.

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