Comments 67
А где картинки? Один текст =(
UFO just landed and posted this here
Хочется воскликнуть: «Наебалово!»
Всё, уважаемые господа и дамы. Критику понял, пост переименовал :)
на самом деле на живых примерах нихрена не понятно :) (ну то есть сужу по своей практики обучения) пока не начнешь разбирать практические примеры, вообще не понятно что такое ООП…
Полностью согласен. Есть ещё практические занятия, на которых мы пишем код, разбираем на примерах что такое, например, полиморфизм, как им пользоваться, зачем он нужен (типичный пример — какая-нибудь абстрактная фабрика).
Тут большие проблемы с теоретическим пониманием того, что же всё таки такое класс. К сожалению, в большинстве источников написано, что это «совокупность полей и методов для работы с ними» — но, на самом-то деле это ещё не класс… Это всё равно как описать человека как «совокупность конечностей и туловища» или «совокупность тела и разума для управления им»…
Тут большие проблемы с теоретическим пониманием того, что же всё таки такое класс. К сожалению, в большинстве источников написано, что это «совокупность полей и методов для работы с ними» — но, на самом-то деле это ещё не класс… Это всё равно как описать человека как «совокупность конечностей и туловища» или «совокупность тела и разума для управления им»…
Ну зачем же сразу в крайности, живые существа, тем более человек — это очень сложные классы, и чтобы их в точности описать сегодняшней науки и мощностей не хватит. Простыми словами — класс это образ сущности (объекта) имеющий определенные свойства (поля) и функции (методы) и являющийся элементом системы (программы). Кстати, если так рассуждать, то класс человека, да и всех живых существ, в их ДНК :)
В том-то и дело, что в классе, по-сути, главное — именно функциональность, т.е. то, что методы и данные увязаны в одно целое и методы производят операции над данными. Важно не то, что класс имеет методы, а то, что эти методы выполняют определённые действия над данными класса (и не только).
А по поводу ДНК — не могу согласиться. ДНК никоим образом не описывает поведение человека. Если уж на то пошло, то ДНК — скорее абстрактная фабрика, которая обеспечивает создание экземпляров разных классов, с одинаковым интерфейсом :).
А по поводу ДНК — не могу согласиться. ДНК никоим образом не описывает поведение человека. Если уж на то пошло, то ДНК — скорее абстрактная фабрика, которая обеспечивает создание экземпляров разных классов, с одинаковым интерфейсом :).
С первым высказыванием согласен, а вот со вторым поспорю :)
ДНК описывает все изначальные параметры человека и весь его функционал, если не ДНК, то что? Поведение уже относится к другой ипостаси, мозгу, самообучающейся нейронной сети (изначальные параметры которой кстати тоже диктуются ДНК). Из этого можно сделать (а можно и не сделать, все ведь относительно ;) ), что ДНК человека это самый настоящий естественный класс, своеобразный и очень сложный, а человек — экземпляр этого класса. Здесь еще многое можно сказать о наследовании, инкапсуляции о социальной надстройке, которая в совокупности образует новый, более глобальный класс (общество), элементами которого являются люди (а где тогда ДНК общества? может в книгах, знаниях, обычаях, а может и нет...).
ДНК описывает все изначальные параметры человека и весь его функционал, если не ДНК, то что? Поведение уже относится к другой ипостаси, мозгу, самообучающейся нейронной сети (изначальные параметры которой кстати тоже диктуются ДНК). Из этого можно сделать (а можно и не сделать, все ведь относительно ;) ), что ДНК человека это самый настоящий естественный класс, своеобразный и очень сложный, а человек — экземпляр этого класса. Здесь еще многое можно сказать о наследовании, инкапсуляции о социальной надстройке, которая в совокупности образует новый, более глобальный класс (общество), элементами которого являются люди (а где тогда ДНК общества? может в книгах, знаниях, обычаях, а может и нет...).
мы как раз сегодня изучали классы.
Нам объясняли на примере ээээ стека =) (мы всю пару его реализовывали, под конец я уже уснул)
Нам объясняли на примере ээээ стека =) (мы всю пару его реализовывали, под конец я уже уснул)
Лично я за семестр что у нас было ООП его совершенно не понял, хотя лабы с богом пополам сделал сам да ещё и одногрупникам помогал.
С ООП я разобрался только когда пришло время курсового. Но сам я его написать с нуля не смог, а взял у одногрупника недоделаную и не работающую толком версию, и переделывал под свой вариант.
Хотя в теории ООП до сих пор плаваю, но понял «нафиг оно вообще надо», как пользоваться, и в чём реально преимущества перед обычными программами.
Так что ИМХО, просто теории и практики мало. Нужно сначала брать уже готовые программы на ООП, и разбирать их, причём не на лекциях на доске, а в качестве практических. Или первые лабораторные делать «изменить некоторые методы в этом классе так-то и так-то», а уж потом самостоятельное составление программ на ООП
С ООП я разобрался только когда пришло время курсового. Но сам я его написать с нуля не смог, а взял у одногрупника недоделаную и не работающую толком версию, и переделывал под свой вариант.
Хотя в теории ООП до сих пор плаваю, но понял «нафиг оно вообще надо», как пользоваться, и в чём реально преимущества перед обычными программами.
Так что ИМХО, просто теории и практики мало. Нужно сначала брать уже готовые программы на ООП, и разбирать их, причём не на лекциях на доске, а в качестве практических. Или первые лабораторные делать «изменить некоторые методы в этом классе так-то и так-то», а уж потом самостоятельное составление программ на ООП
Вообще, цель курса не обучить ООП, а показать, что такое паттерны проектирования. Подразумевается, что к этому моменту студент ООП уже знает и это как бы повторение. Т.е. они уже писали и на C++ и на Java, но понимания, что такое public class Foo на самом деле, у них нет. Большинство, к сожалению, считает, что это магическое заклинание.
вспоминается цитата с баша:
А если серьезно, то имхо, рассказывать ООП с нуля студентам нужно в тот момент когда они еще ничего не знают ни про C# ни про Java, так сказать, сферическое ООП в вакууме.
Волею судеб начал не так давно программировать на C#. И все бы ничего, но, по непонятной причине, меня начало переть с довольно часто встречающейся в нем конструкции — public static void
Долго думал, с чего бы это. И через неделю меня осенило. Ведь это же по ударениям — один в один всем знакомое с детства КРИБЛЕ КРАБЛЕ БУМС!
А если серьезно, то имхо, рассказывать ООП с нуля студентам нужно в тот момент когда они еще ничего не знают ни про C# ни про Java, так сказать, сферическое ООП в вакууме.
Боюсь, в этом случае они абсолютно ничего не поймут. Главное — у них не будет мотивации понимать. Как, по большому счёту, нет мотивации разбираться с каким нибудь термехом или урматами у большинства студентов направления computer since.
Я, конечно, не говорю про отдельные исключения. Мне, например, термех нравился ;).
Я, конечно, не говорю про отдельные исключения. Мне, например, термех нравился ;).
Я конечно еще не преподаю, зато многие нюансы преподавателей со своей кафедры замечал. Например, мне на первом курсе дали задание написать клиент-серверный чат, многопоточный, по протоколу TCP, на C#.
Представьте, первый курс, а тут такое. А на кону зачет. Меня «заинтересовали», с тех пор я программирую на C# (уже 2.5 года, получается).
Бывают студенты, которые не понимают потому что не хотят погружаться в материал.
Согласитесь, если вы в качестве зачета (не знаю какая у вас форма отчетности, но допустим зачет)заставите попросите их написать какое-нибудь несложное приложение с использованием основных паттернов и раскрытием концепций ООП, то им волей — неволей придется вникнуть в то, что это такое.
Если студенту интересно, он решит такую задачу на раз, разберется, поймет что ничего не знает и начнет развиваться. Если студенту стало интересно в процессе, то все тоже довольно радужно, а вот если студент забьет, попросит скромного «шарящего» студента написать за него программу, то он с тем же успехом спишет на экзамене, такие всегда есть и будут.
Главное не вдаваться в крайности, то есть можно зверствовать ради того, чтобы всех вынести, а можно поставить требования чуть выше среднего и помогать студентам взять эту планку, быть открытым к вопросам и разбираться вместе с теми, кто хочет, но не понимает.
Представьте, первый курс, а тут такое. А на кону зачет. Меня «заинтересовали», с тех пор я программирую на C# (уже 2.5 года, получается).
Бывают студенты, которые не понимают потому что не хотят погружаться в материал.
Согласитесь, если вы в качестве зачета (не знаю какая у вас форма отчетности, но допустим зачет)
Если студенту интересно, он решит такую задачу на раз, разберется, поймет что ничего не знает и начнет развиваться. Если студенту стало интересно в процессе, то все тоже довольно радужно, а вот если студент забьет, попросит скромного «шарящего» студента написать за него программу, то он с тем же успехом спишет на экзамене, такие всегда есть и будут.
Главное не вдаваться в крайности, то есть можно зверствовать ради того, чтобы всех вынести, а можно поставить требования чуть выше среднего и помогать студентам взять эту планку, быть открытым к вопросам и разбираться вместе с теми, кто хочет, но не понимает.
Вот с этим согласен на 100%. По большому счёту, в рамках курса по архитектуре именно «практика — критерий истины».
К сожалению, никак не успеваю придумать «аккумулирующее» задание по нескольким паттернам. Но на каждой паре на примере мини-приложения (обычно — реального, взятого из моего програмистского прошлого) разбираемся, как тот или иной паттерн работает. Т.е. я ставлю задачу например «написать за пару базовую архитектуру и функциональность прокси с кэшированием». Реально — пара классов с общим интерфейсом и делегированием (ну, собственно, паттерн «прокси»).
И, что самое удивительное, с такой достаточно сложной тематикой и архитектурой справляются практически все.
К сожалению, никак не успеваю придумать «аккумулирующее» задание по нескольким паттернам. Но на каждой паре на примере мини-приложения (обычно — реального, взятого из моего програмистского прошлого) разбираемся, как тот или иной паттерн работает. Т.е. я ставлю задачу например «написать за пару базовую архитектуру и функциональность прокси с кэшированием». Реально — пара классов с общим интерфейсом и делегированием (ну, собственно, паттерн «прокси»).
И, что самое удивительное, с такой достаточно сложной тематикой и архитектурой справляются практически все.
Значит вы на верном пути.
Это конечно может уже попахивать садизмом, но все же: если все все успевают, значит можно попробовать чуть поднять планку, пример так сразу в голову не приходит, но я думаю вы понимаете о чем я.
Плюсы такого «садизма» вполне очевидны: если успеют и это, то будет явный рост профита образовательного процесса.
Из минусов можно выделить разве что «отношение к преподавателю как к садисту», но искусство требует жертв.
Может быть вырастет поколение гениальных программистов, а Вы к этому еще и руку приложите )
Это конечно может уже попахивать садизмом, но все же: если все все успевают, значит можно попробовать чуть поднять планку, пример так сразу в голову не приходит, но я думаю вы понимаете о чем я.
Плюсы такого «садизма» вполне очевидны: если успеют и это, то будет явный рост профита образовательного процесса.
Из минусов можно выделить разве что «отношение к преподавателю как к садисту», но искусство требует жертв.
Может быть вырастет поколение гениальных программистов, а Вы к этому еще и руку приложите )
Не думаю, что имеет смысл требовать чего-то большего. Если обучение комфортно (особенно на пятом курсе), то знания усваиваются лучше. Тем более, половине из них ещё диплом защищать — лишняя нагрузка ни к чему.
А про воспитание хороших программистов — исключительно на производстве и, желательно, у меня в команде. Я же тоже в вузе не только для развлечения работаю ;). Head hunting в таком виде максимально эффективен.
А про воспитание хороших программистов — исключительно на производстве и, желательно, у меня в команде. Я же тоже в вузе не только для развлечения работаю ;). Head hunting в таком виде максимально эффективен.
поделюсь своим опытом.
Мой преподаватель, объяснявший нам что такое паттерны и с чем их едят (я весь курс слушал с горящими глазами) задание придумал следующее (он его еще лет 5 назад наверное придумал, но выглядело это так, как будто только что): построенный на ООП анализатор алгебраических выражений с возможностью их вычислять. Для хранения дерева выражения используется композит (выражение, от которого наследуются константа, переменная, сложное выражение), для их строительства — билдер (по одному на каждый класс), потом для того, чтобы переменные хранились только один раз — диспетчер какой-нибудь, дальше семестр заканчивался.
Еще был интересный проект для диплома — графический редактор блок-схем: шаблоны фасад, наблюдатель, композит, медиатор, билдер конечно же, может еще парочку. Но это сложнее, чем первый. Надеюсь, поможет.
А вообще я паттерны люблю, пишите еще :)
Мой преподаватель, объяснявший нам что такое паттерны и с чем их едят (я весь курс слушал с горящими глазами) задание придумал следующее (он его еще лет 5 назад наверное придумал, но выглядело это так, как будто только что): построенный на ООП анализатор алгебраических выражений с возможностью их вычислять. Для хранения дерева выражения используется композит (выражение, от которого наследуются константа, переменная, сложное выражение), для их строительства — билдер (по одному на каждый класс), потом для того, чтобы переменные хранились только один раз — диспетчер какой-нибудь, дальше семестр заканчивался.
Еще был интересный проект для диплома — графический редактор блок-схем: шаблоны фасад, наблюдатель, композит, медиатор, билдер конечно же, может еще парочку. Но это сложнее, чем первый. Надеюсь, поможет.
А вообще я паттерны люблю, пишите еще :)
Когда мы проходили ООП, нам тоже втюхивали примеры с автомобильчиками. И знаете, по-моему это достаточно неудачная идея. По-крайней мере могу сказать что тогда это не помогло осмыслить ООП ни одному человеку.
Абсолютно согласен. Пример с автомобилем ни в какие ворота не лезет. На мой взгляд он только вносит путаницу, проще понять на примерах про объект и методы.
Вы можете порекомендовать, в каком изложении ООП было бы наиболее понятным для Вас лично? Если не трудно, привести «пример про объект и методы»? Был бы очень благодарен.
В контексте популярной ныне архитектуры MVC можно рассказать про Модель. Причем, не только про то, что есть некие данные 'title', 'speed' и методы 'save'… А рассказать на примере наследования, как все удобно и просто работает. (Вот описание создания своей модели путем наследования на Django).
В чем фишка то? — в том, что не надо заново писать код. Что данные могут проверяться. Что это удобно и быстро. Покажите быстрый пример с наследованием, а потом покажите, сколько пришлось бы писать с нуля.
А то с примерами на автомобилях у меня было представления, что ООП годится, только чтобы игры писать.
В чем фишка то? — в том, что не надо заново писать код. Что данные могут проверяться. Что это удобно и быстро. Покажите быстрый пример с наследованием, а потом покажите, сколько пришлось бы писать с нуля.
А то с примерами на автомобилях у меня было представления, что ООП годится, только чтобы игры писать.
А мне про чайник нравиться пример.
Особенно с абстрактным чайником и наследованием его в газовый и электрический.
Особенно с абстрактным чайником и наследованием его в газовый и электрический.
Помню читал когда-то Гради Буча, там были примеры с растениями. На этих примерах объяснялось наследование, как наследуются общие свойства и характеристики, поведение.
Но, этот пример также можно использовать для понятия Класс и Объект: например, есть класс «Цветок» который имеет свойство цвет, рост и др. Объект, допустим, «роза» красного цвета и определенным размером куста.
Кстати, в той книге Буча, было достаточно много примеров, которые вам могут пригодиться. Название, возможно, знакомо: Объектно-ориентированный анализ и проектирование.
Но, этот пример также можно использовать для понятия Класс и Объект: например, есть класс «Цветок» который имеет свойство цвет, рост и др. Объект, допустим, «роза» красного цвета и определенным размером куста.
Кстати, в той книге Буча, было достаточно много примеров, которые вам могут пригодиться. Название, возможно, знакомо: Объектно-ориентированный анализ и проектирование.
Нас учили на примере геометрических фигур, я тогда тоже ничего не понял… хотя щас кажется, что это довольно понятное объяснение. А вот автомобиль мне тоже не нравится, лучше бы объяснять ооп на примере чего-то не представляющего настолько единый объект, а на том где очевидно можно выделить составляющие. Нет, конечно и у автомобиля тоже можно выделить, но он хочет восприниматься сразу как единая сущность и это может сбить с толку.
А мне понравились аналогии, весьма доступно и понятно. Продолжайте, пожалуйста!
я вот «пишу на 1с» там никаких классов нет. ну как минимум название не используется. С автомобилем худо-бедно ассоциация понятна. но как он выглядит… не представляю. Воображение рисует функцию с параметрами, как наиболее близкий аналог… старательно перечитал дважды… если цель, чтобы точно поняли постарайтесь картинку какую-то предъявить… и может пример какой-то. хотя не представляю как выглядит пример. Говорю, как человек не знакомый с ОПП: что-то понятно, но не окончательно.
Спасибо, буду думать, как это лучше описать.
Но, исключительно для оправдания: на самом деле, целевая аудитория ООП в том или ином виде знает. Поэтому данный текст рассчитан скорее на «освежение» этих знаний и, я надеюсь, позволяет взглянуть на это с другого ракурса, понять, что ООП — это не обязательно «способ писать компьютерную программу», но и, в некотором роде, встречается в реальном мире.
Но, исключительно для оправдания: на самом деле, целевая аудитория ООП в том или ином виде знает. Поэтому данный текст рассчитан скорее на «освежение» этих знаний и, я надеюсь, позволяет взглянуть на это с другого ракурса, понять, что ООП — это не обязательно «способ писать компьютерную программу», но и, в некотором роде, встречается в реальном мире.
У нас на курсе были те же проблемы.
Никто не понимал, что такое класс, что такое объект, а главное — «в чем разница». Я ООП очень люблю, я его везде «вижу». Когда-то для себя в качестве примера провела аналогию не с автомобилем (в котором большинство студентов не ездит), а с лифтом. Класс — это проект лифта. Именно проект. Ну, т.е., то, каким он будет. У него есть высота, ширина, скорость — это свойства. Он умеет ездить — вверх/вниз, это методы. То, что стоит у нас в домах — это экземпляры класса «Лифт», у которых есть свой номер (у каждого). А интерфейс — это кнопки. По проекту мы можем наштамповать этих лифтов столько, сколько угодно. Можем менять им в процессе цвет двери, например (паблик чтение/запись свойства), но не можем менять скорость, которая постоянна (паблик рид свойство). У него есть куча внутренних свойств, которые нам неведомы, но благодаря им лифт работает.
Ну, вот у меня какая-то такая когда-то аналогия возникла. Конечно, не так красиво, как с автомобилем. И не факт, что понятнее. Но поделиться… :)
Никто не понимал, что такое класс, что такое объект, а главное — «в чем разница». Я ООП очень люблю, я его везде «вижу». Когда-то для себя в качестве примера провела аналогию не с автомобилем (в котором большинство студентов не ездит), а с лифтом. Класс — это проект лифта. Именно проект. Ну, т.е., то, каким он будет. У него есть высота, ширина, скорость — это свойства. Он умеет ездить — вверх/вниз, это методы. То, что стоит у нас в домах — это экземпляры класса «Лифт», у которых есть свой номер (у каждого). А интерфейс — это кнопки. По проекту мы можем наштамповать этих лифтов столько, сколько угодно. Можем менять им в процессе цвет двери, например (паблик чтение/запись свойства), но не можем менять скорость, которая постоянна (паблик рид свойство). У него есть куча внутренних свойств, которые нам неведомы, но благодаря им лифт работает.
Ну, вот у меня какая-то такая когда-то аналогия возникла. Конечно, не так красиво, как с автомобилем. И не факт, что понятнее. Но поделиться… :)
не-не оправдание не нужно. ваши то знают, это я пока далек, надо будет-придется брать какую-то книжку и разбираться. пока ещё нет такой необходимости.
а ниже про лифт тоже в принципе понятный пример)
а ниже про лифт тоже в принципе понятный пример)
Уверен, что главной проблемой при изучении ООП является терминология. Когда я впервые услышал «полиморфизм», «инкапсуляция», у меня на долгое время пропала программистская потенция. Считаю, что первым делом нужно вообще запретить пользоваться терминологией ООП и вводить её только после того, как окончательно усвоена суть.
Еще смущает что человеку совсем далекому от ООП вы сразу же даете кучу терминов — «С точки зрения программирования класс можно рассматривать как набор данных (полей, атрибутов, членов класса) и функций для работы с ними (методов).
С точки зрения структуры программы, класс является сложным типом данных.» каких полей каких атрибутов… сложным типом относительно чего!?
а так вполне:-)
С точки зрения структуры программы, класс является сложным типом данных.» каких полей каких атрибутов… сложным типом относительно чего!?
а так вполне:-)
Спасибо.
Очень надеюсь, что те будущие программисты, которым я курс читаю, не совсем далеки от ООП (хотя, глядя на них, иногда сомневаюсь:) ).
А про сложный тип — относительно «простого типа данных» естественно :).
Очень надеюсь, что те будущие программисты, которым я курс читаю, не совсем далеки от ООП (хотя, глядя на них, иногда сомневаюсь:) ).
А про сложный тип — относительно «простого типа данных» естественно :).
Ну вот возьмем к примеру меня:)как то так сложилось что я всю сознательную жизнь в кручусь в IT сфере, за всю жизнь у меня не получилось научится программировать — по разным причинам, то не было достойного учителя то скушные маны и учебники нагоняли тоску то не было интересных задач. Я уже заканчиваю универ, в нем преподавали С++ на первом курсе, оттуда я не помню ничего — не заинтересовали, сейчас я осознаю что пора менять ситуацию, начинаю интересоваться… вот ваша статья надеюсь будет стартом, она уже в закладках.
ЗЫ, я учусь по специальности «Информационные системы и технологии» и надеюсь в этой сфере неплохой специалист:)
ЗЫ, я учусь по специальности «Информационные системы и технологии» и надеюсь в этой сфере неплохой специалист:)
Вы не поверите, как же я долго вбивал в себе в голову суть ООП. Я до сих пор, как это видно сейчас, где только не нахожу альтернативные статьи с разьяснениями такого подхода к программированию с удовольствием читаю и заново переделываю свои шаблоны. Хоть, ооп для меня уже давно понятно, ясно и используется. Очень наглядный пример, спасибо — это интересно :)
Класс – это способ описания сущности, определяющий состояние и поведение, зависящее от этого состояния, а также правила для взаимодействия с данной сущностью (контракт).
Какой ужасный, ужасный канцелярит. Подобные описания хороши в учебнике, но никак не в курсе популяризации.
А пример с машинками он не просто вреден, он архивреден!
Хоть он и канониченЪ, но он на корню губит идею сложных объектов и агрегации. Человек, который привык работать с «машинками» очень долго доходит до понимания того, что иногда не объект «дверь» агрегирует объект «замочная скважина», а наоборот.
иногда не объект «дверь» агрегирует объект «замочная скважина», а наоборот.
Прям как в книжках про волшебников. Вставляешь ключ и появляется дверь :)
Примитивный пример: есть сущности «статья» и «категория», статьи принадлежат категориям.
Все понимают на примере машинок, что у объекта «категории» может быть свойство — коллекция объектов «статья».
Но некоторые могут не понять, что у объекта «статья» может быть свойство — объект «родительская категория», т.к. в физическом мире «машинок» бОльший объект не может лежать внутри меньшего.
Все понимают на примере машинок, что у объекта «категории» может быть свойство — коллекция объектов «статья».
Но некоторые могут не понять, что у объекта «статья» может быть свойство — объект «родительская категория», т.к. в физическом мире «машинок» бОльший объект не может лежать внутри меньшего.
Хм… Пример «родительской категории» в машине является завод изготовитель. Или я что-то недопонимаю в ваших объяснениях.
Абсолютно верно, но неочевидно для начинающих :)
Заметьте, в качестве примеров методов и свойств машины в 95% выступают такие методы и свойства, как: «номер машины», «завести», «залить бензин», т.е. некие «физические» объекты, которые находятся внутри машины.
А потом новички с удивлением обнаруживают, что в машине находятся не только сиденье с багажником, но и завод, в котором в свою очередь находится город. И вообще, машина нужна исключительно для того, чтобы предоставить интерфейс для доступа к городу :)))
Заметьте, в качестве примеров методов и свойств машины в 95% выступают такие методы и свойства, как: «номер машины», «завести», «залить бензин», т.е. некие «физические» объекты, которые находятся внутри машины.
А потом новички с удивлением обнаруживают, что в машине находятся не только сиденье с багажником, но и завод, в котором в свою очередь находится город. И вообще, машина нужна исключительно для того, чтобы предоставить интерфейс для доступа к городу :)))
А вот с последнее ваше дополнение, по-моему, автору топика стоит добавить в свои лекции, для более лучшего понимания темы :)
Спасибо :)
На самом деле, ООП — это именно та вещь, которая представляет собой типичный случай зависимости от масштаба.
Чем сложнее проект, тем большее количество паттернов вовлекается в работу, тем не-нативнее и не-«физичнее» становится система, и наступает тот момент, когда Алиса открывает дверь Кроликом, который агрегирует Льюиса Кэролла, у которого в кармане лежит ключ.
На самом деле, ООП — это именно та вещь, которая представляет собой типичный случай зависимости от масштаба.
Чем сложнее проект, тем большее количество паттернов вовлекается в работу, тем не-нативнее и не-«физичнее» становится система, и наступает тот момент, когда Алиса открывает дверь Кроликом, который агрегирует Льюиса Кэролла, у которого в кармане лежит ключ.
Да, спасибо. Обязательно добавлю про завод. Действительно, наглядно и важно.
Пример класса — целое число.
Экземпляр класса — 1, 8, 42, -16.
Вообще, даже на самом старте не было сложностей с разделением класса и объекта.
Экземпляр класса — 1, 8, 42, -16.
Вообще, даже на самом старте не было сложностей с разделением класса и объекта.
Если уж давать ООП для тех, кто хоть один язык худо-бедно знает, то начинать надо со смолтолковской объектной модели, а потом уже показывать, почему в традиционных языках она превратилась в структуры+интерфейсы.
Давать определение интерфейса как публичные методы класса не совсем верно.
Последовательность по идее должна быть такой — интерфейс, реализация интерфейса (конкретный класс), объект (экземпляр класса)
Последовательность по идее должна быть такой — интерфейс, реализация интерфейса (конкретный класс), объект (экземпляр класса)
Спасибо! Очень нужная тема, как раз пробую вникнуть в ООП, но после си плохо все идет((
Ждем продолжения :)
Ждем продолжения :)
c такими определениями класса и интерфейса, немудрено, что «большинство испытывают затруднения даже с пониманием основных терминов ООП»
Я в своих лекциях обычно начинаю даже не с классов и объектов — а со способов декомпозиции — чтобы было понятно, зачем вообще нужно делить систему на классы. Рассказываю на примере чайников. :)
Еще важно показать, что поведение объекта зависит от его состояния и это одна из фишек, которая отличает его от просто структуры с набором функций. В примере с автомобилем — нажатие на педаль газа будет работать по-разному в зависимости от состояния автомобиля. Если автомобиль не заведен — то педаль газа ничего не будет делать. Если завести автомобиль, то он перейдет в состояние заведен и тогда нажатие педали газа будет действовать на него по-другому.
Состояние объекта может меняться благодаря внешнему воздействию (например, переключили передачу) или внутренним действиям (бензин кончился).
Еще важно показать, что поведение объекта зависит от его состояния и это одна из фишек, которая отличает его от просто структуры с набором функций. В примере с автомобилем — нажатие на педаль газа будет работать по-разному в зависимости от состояния автомобиля. Если автомобиль не заведен — то педаль газа ничего не будет делать. Если завести автомобиль, то он перейдет в состояние заведен и тогда нажатие педали газа будет действовать на него по-другому.
Состояние объекта может меняться благодаря внешнему воздействию (например, переключили передачу) или внутренним действиям (бензин кончился).
Зависимость поведения от состояния — это частный случай. Существуют объекты сразу готовые для использования после создания.
В примере с автомобилем — есть функция интерфейса «Завести автомобиль» которую необходимо вызвать перед использованием других функций(не всех) автомобиля. Но вполне возможен гипотетический вариант когда при нажатии на педаль газа автомобиль сам заводится и начинает движение.
В примере с автомобилем — есть функция интерфейса «Завести автомобиль» которую необходимо вызвать перед использованием других функций(не всех) автомобиля. Но вполне возможен гипотетический вариант когда при нажатии на педаль газа автомобиль сам заводится и начинает движение.
Разумеется, бывают методы, которые не зависят от состояния, но тогда они мало отличаются от обычных функций и их, кстати, часто даже делают статическими в целях оптимизации.
В данном случае объект тоже готов к использованию после создания. Завести автомобиль в данном случае — не аналог конструктора или Init, а полноценное действие. Вы ведь можете завести автомобиль, поездить, а потом заглушить мотор переводя его опять в начальное состояние.
Я обычно привожу пример с автоматом. Есть режим переключения стрельбы — одиночные и очередь. В зависимости от текущего режима и кол-ва патронов, один и тот же метод Fire работает по-разному (поведение зависит от состояния). По мере стрельбы кол-во патронов уменьшается (состояние изменяется).
Без ООП мы бы вызывали что-то вроде Fire(ammoCount, burstMode), а в ООП вся информация хранится в объекте и мы вызываем просто Fire().
Требование инициализации для работы некоторых методов действительно не очень хорошее решение и лучше выполнять инициализацию по мере необходимости (как, например, в Singleton и LazyLoad).
В данном случае объект тоже готов к использованию после создания. Завести автомобиль в данном случае — не аналог конструктора или Init, а полноценное действие. Вы ведь можете завести автомобиль, поездить, а потом заглушить мотор переводя его опять в начальное состояние.
Я обычно привожу пример с автоматом. Есть режим переключения стрельбы — одиночные и очередь. В зависимости от текущего режима и кол-ва патронов, один и тот же метод Fire работает по-разному (поведение зависит от состояния). По мере стрельбы кол-во патронов уменьшается (состояние изменяется).
Без ООП мы бы вызывали что-то вроде Fire(ammoCount, burstMode), а в ООП вся информация хранится в объекте и мы вызываем просто Fire().
Требование инициализации для работы некоторых методов действительно не очень хорошее решение и лучше выполнять инициализацию по мере необходимости (как, например, в Singleton и LazyLoad).
"… приборная панель автомобиля, которая позволяет вызвать такие методы, как увеличение скорости, торможение, поворот, переключение передач, включение фар..."
А как приборная панель может влиять на увеличение скорости и торможение? Я думал на педальки давить нужно :)
А как приборная панель может влиять на увеличение скорости и торможение? Я думал на педальки давить нужно :)
прежде чем учить ООП, нужно понять, что ООП бывает и без слова Class. Советую объяснять примеры с людьми и их взаимоотношениями. вместо машины направьте взор на самую симпатичную девушку на потоке, на её примере объясняйте объекты, атрибуты, методы взаимодействия с внешним миром.
будет куча споров. вам не нужно объяснять что такое класс и интерфейс, заставьте их вспомнить об ооп из жизни.
будет куча споров. вам не нужно объяснять что такое класс и интерфейс, заставьте их вспомнить об ооп из жизни.
Sign up to leave a comment.
ООП с примерами (часть 1)