Простой вопрос(ООП и лифт)

[dimagolov]

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

p.s. у меня тема про лифт вызвала ассоциацию с предсказанием ветвлений в блоках предварительной выборки конвеерных CPU

 

[AmdY]

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

поэтому может начнём с того, что топикстартер хотел продемонстрировать в классе лифт, какие условия тот должен был выполнятью?

 

[craz]

Автор оригинала: dimagolov
Mols, кнопки и отпечатки это ерунда, так как лифт может везти не тех, кто нажимает кнопки, поэтому конкретно этот аспект малоинтересен. а вот определить по весу кто зашел и куда поехал вполне интересно, особенно в контексте того, что было нажато и в какой последовательности в этот период. чтобы собирать статистику и делать предсказания куда поедет пассажир, который вызвал лифт.

p.s. у меня тема про лифт вызвала ассоциацию с предсказанием ветвлений в блоках предварительной выборки конвеерных CPU

офигеть новый экземпляр класса,

$лифт_похититель = new Лифт('жертва не нажимавшая кнопки');

-~{}~ 11.05.10 15:40:

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

поэтому может начнём с того, что топикстартер хотел продемонстрировать в классе лифт, какие условия тот должен был выполнятью?

я ТС с самого С Т не видел в Т, так что об этом история видимо умолчит)

 

[cDLEON]

phprus
Этаж может быть не только №1, №н, ещё может быть нечто вроде "гостиница, гараж" и т.д. и т.п, естественно со своей логикой внутри. И пассажиру нужно двигаться.
У лифта могут быть состояния: стоит, едет туда, ждёт реакции юзера и т.д.
Как то так.
Телега, знаете ли, тоже может иметь только свойства х,у,z и больше ни чего. Если опустить остальные объекты внешнего мира.

 

[Mols]

Автор оригинала: dimagolov
Mols, кнопки и отпечатки это ерунда, так как лифт может везти не тех, кто нажимает кнопки, поэтому конкретно этот аспект малоинтересен. а вот определить по весу кто зашел и куда поехал

Ы)))
Сразу видно редко Вы взвешиваетесь)))
В общем колебания массы человека в пределах 5% это очень даже спокойно может быть (даже за одни сутки).
За больший период так вообще.
+ разная одежда.
Итого метод определения пассажира по весу будет иметь такую погрешность, что мама не горюй.
Хотя отпечатки тоже не панацея) Можно и в перчатках кнопки нажимать.
можно было бы по запаху идентифицировать... вроде тоже есть уникальный для каждого запах.... так ведь гады начнут ездить в гидрокостюмах.

 

[dimagolov]

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

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

 

[Фанат]

но чем-то я согласен с triumvirat
чем балаболить - действительно, писали бы код уже

 

[phprus]

craz

где придел тех границ про которые говорит phprus - что считать достойным объектом для того, чтобы на его основе изучать ООП?

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

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

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

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

cDLEON

Этаж может быть не только №1, №н, ещё может быть нечто вроде "гостиница, гараж" и т.д. и т.п, естественно со своей логикой внутри. И пассажиру нужно двигаться.

От имени метки этажа суть не меняется. А название этажа врядли может поменять то, как работает лифт.

У лифта могут быть состояния: стоит, едет туда, ждёт реакции юзера и т.д.

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

 

[Фанат]

Начать можно с упрощенной модели.

 

[fixxxer]

Начать лучше с прорисовки UML-диаграммы классов/интерфейсов. Раз уж изучаем.

После чего ее выложить, а мы, это, расскажем, почему ты дурак.=)

 

[флоппик]

кстати, концептуальный вопрос. сколько кнопок делать на этаже (не крайнем)? одну или две?

У нас в больнице были такие лифты. 4 лифта, 8 кнопок(!) (т.к. в больнице были подземные этажи)
Уехать на лифте в НУЖНОЕ место с ЛЮБОГО этажа было не реально. Потому что народ тупо жал ВСЕ-ВСЕ кнопки. Поведение лифта было непредсказуемым абсолютно.
Я сторонник "One button to rule them all(tm)" и умных лифтов.

-~{}~ 11.05.10 20:43:

Начать можно с упрощенной модели.

Лифт - хороший пример потому что задача очень легко расширяется и усложняется, требуя задействовать для решения все больше особенностей ООП, не теряя накопленной логики, и внося мало неоднозначности.
phprus, нескромный вопрос - ты пробовал обучать других?

 

[whirlwind]

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

 

[флоппик]

whirlwind, тот же вопрос хочу задать тебе -

ты пробовал обучать других?

? без обид, просто интересно?

 

[phprus]

флоппик

нескромный вопрос - ты пробовал обучать других?

Да. И пока даже успешно. Но так как подобный опыт у меня был НЕ не в рамках преподавательской деятельности, то так уж получилось, что обучать мне приходилось только людей заинтересованных в обучении, а с такими проще (их не надо заинтересовывать, а это в преподавании сложнее всего).

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

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

 

[флоппик]

С такой точкой зрения я согласен.

Все, понял, вопрос снят. ) Жму руку. )

обучать мне приходилось только людей заинтересованных в обучении, а с такими проще (их не надо заинтересовывать, а это в преподавании сложнее всего)

у людей "незаинтересованных" (читай, не знающих точно, что хотят быть программистами) развитое абстрактное мышление бывает у одного из человек 30. Они просто НЕ ПОНИМАЮТ нереальных примеров, непривязанных к некоей физической реализации. Это жутко выматывает )
Ну и есть разница между "помогать учится" и "учить" ) Вообще, это самый неблагодарный труд, ящитаю)

 

[phprus]

whirlwind

Изучать ООП на конкретных примерах это примерно как учиться рисовать упорно изображая фрукты в вазе.

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

Искусство ООП в том, как объекты взаимодействуют, а не в том какие это объекты.

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

 

[whirlwind]

флоппик Да.

С ООП лучше сразу осознать, что это проектирование, а не кодирование. У меня на столе лежит старенькая книга ISBN 0-13-303678-2. Так вот там на протяжении всей книги, не поверите, проектируется лифт.

-~{}~ 11.05.10 18:53:

phprus ну я к тому, что можно взять все что угодно. Лифт это будет или карточная игра - не столь важно. Главное рассматривать систему объектов. А когда в качестве примера берут один обособленный объект, то в итоге получается blob и гавнакод впоследствии.

 

[A1x]

А вот задачка довольно хороша для ООП, как раз.
Ибо лифт сущность однозначная, имеет несколько состояний, и поведение, зависящее от этих состояний. Золото-пример для изучения ООП.

лифт- это классический пример который разбирают при изучении конечных автоматов, по определению

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

как это реализовывать- в виде ООП, на асм"е или еще как - другой вопрс. Если интересно - ссылка с первой страницы гугла -
Искусство программирования лифта. Объектно-ориентированное программирование с явным выделением состояний

 

[флоппик]

как это реализовывать- в виде ООП, на асм"е или еще как - другой вопрс.

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

 

[whirlwind]

Вообще в ооп самое сложное для понимания (прелестей) это полиморфизм. В проекте лифта где хороший пример полиморфизма? Я с ходу не вижу.