Здравствуйте, VladD2, Вы писали:

VD>Пример должен быть:
VD>* Кратким. Я должен легко описать его в рамках одной статьи (10-15) страниц (по 5 тысяч знаков без учета пробелов).
VD>* Он должен демонстрировать наследование, виртуальные методы, события. Хорошо бы, но не обязательно, чтобы он так же демонстрировал использование интерфейсов.
VD>* Понятным.
VD>* Не абстрактным и практичным. Меня самого всегда раздражало когда ООП подавали на совершенно не реалистичных примерах вроде построения иерархии животных или библиотеки графических примитивов (которые на практике никакого ООП не используют).
VD>* Возможно, но не обязательно, связан с примером строчного калькулятор.

Может игру какую простую взять, типа тетриса или арканоида с несколькими уровнями.

Здравствуйте, VladD2, Вы писали:

D>>А кому-то такие абстрактные примеры помогают постичь суть вещей, ибо сами числа Фибоначчи почти не несут дополнительной нагрузки.

VD>Взглянуть бы на них.

На примере этих чисел очень хорошо постигать потоки. Те самые, которые мы дружно выпилили из самой первой версии comp, заменив дотнетовским yield.

Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, VladD2, Вы писали:

M>Generic alpha-beta перебор, заточенный под любую игру. Ну и выбрать пару игр, чтобы была иерархия.

Игра — это само по себе неплохая идея!
А вот с "Generic alpha-beta перебором" не знаком, к сожалению. В чем его прелесть?
Имеется в виду вот это: http://en.wikipedia.org/wiki/Alpha-beta_pruning ?

M>Получаем примерно следующее:
M> интерфейс IGame, в котором реализуется NewGame, DoMove, [UndoMove,] GenMoves, State
M> абстрактный класс TGame8x8 (игра на доске 8x8 или около того)

Играем в шахматы? Не круто ли для примера?

M> классы TChess, TDraught, ...
M> класс TAlphaBetaEngine, который реализует alpha+beta перебор, и в котором есть куча event-ов на те или иные события, связанные с визуализацией поиска: изменение текущего хода, глубина, процент, ...

Это уже точно перебор.

Но сама идея использовать игру в качестве примера — это хорошая идея. Игра — это почти всегда симуляция. А где есть симуляция, там ООП подходит отлично. Подумаю над этим вопросом.

Здравствуйте, dsorokin, Вы писали:

D>На примере этих чисел очень хорошо постигать потоки. Те самые, которые мы дружно выпилили из самой первой версии comp, заменив дотнетовским yield.

Это перебор уже. Вот идея использовать игру для введения ООП-фич мне больше нравится.

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

Здравствуйте, BulatZiganshin, Вы писали:

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

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

Поэтому ИМХО тут два варианта — либо кошки с собаками, либо брать-таки ГУЙ и писать задачу, связанную с расширением функционала какого-нибудь контрола, имеющего ООП-ный дизайн (т.е. ситуацию, где мы *вынуждены* использовать ООП). Собственно, мой вариант — расширение вполне себе ООП-ного DataGridView из вин-формсов.

Здравствуйте, D. Mon, Вы писали:

DM>Вообще, именно GUI — отличный пример для ООП. Где всякий контрол есть окно (т.е. объект), которое может получать сообщения и реагировать на них. И поведение можно наследовать и переопределять.

Это я и сам понимаю. Но проблема в том, том что в простых случаях как-то ООП (по крайней мере бенефиты от него) не видны, а сложные случаи уже плохо применимы в качестве примеров. Не могу же я скажем редактор текста привести как пример?

DM>В принципе, когда в языке есть мощные средства помимо ООП, подходящих задач для него остается не так много. В основном это те, где нужно позднее связывание.

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

Здравствуйте, BulatZiganshin, Вы писали:

BZ>для начала бы не помешало выяснить какое ООП мы вообще собираемся демонстрировать. ибо оно бывает весьма разным

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

Именно. Язык ведь базируется на дотнете где ООП классовый.

BZ>проблема как мне кажется в том, что такое — полноценное — использование ООП требуется в достаточно больших проектах.

Именно.

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

Ага. Более того. Тот же ГУЙ, как оказалось клепается в ВинФормс на событиях (которые тоже ссылки на фунции, по большому счету) и при этом нет нужды ни в наследовании, ни в переопределении методов.

BZ>у меня лично в прикладной программе наиболее развитаяиерархия классов была когда я делал иерархию типов форм в изнес-приложении. что-то в таком духе:

BZ>любая форма
BZ>-диалог запроса
BZ>-форма с источником данных...

Дык не повторять же реализацию ВинФормсов только для того чтобы продемонстрировать ООП? Хотя это было бы как раз весьма неплохим примером.

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

Здравствуйте, BulatZiganshin, Вы писали:

BZ>нельзя так Влад. улыбаясь на работе, ты крадёшь деньги работодателя!

Ага. Причем самое обидное, что это как раз и есть мои деньги .

BZ>да и вообще — предлагаю во всех раздела форума отменить смайлы для твоего личного удобства

ОК. Подумаем над этим предложением.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ты уж определись, что тебе надо — реальную жизнь или то, что ты писал чуть выше по треду

Цитирую себя любимого:

Пример должен быть:
* Кратким. Я должен легко описать его в рамках одной статьи (10-15) страниц (по 5 тысяч знаков без учета пробелов).
* Он должен демонстрировать наследование, виртуальные методы, события. Хорошо бы, но не обязательно, чтобы он так же демонстрировал использование интерфейсов.
* Понятным.
* Не абстрактным и практичным. Меня самого всегда раздражало когда ООП подавали на совершенно не реалистичных примерах вроде построения иерархии животных или библиотеки графических примитивов (которые на практике никакого ООП не используют).
* Возможно, но не обязательно, связан с примером строчного калькулятор.

V>>Материал рассчитан как минимум на новичков в языке. А по уму на новичков в программировании.

PD>Эти вещи плохо совместимы.

Знаю. Иначе бы и вопросы не задавал. Но ведь решать простые задачи не интересно!

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

ANS>Связь между существованием линий и методой ООП не раскрыта. Её, кстати, и нет — так что не ищи.
ANS>Ты хочешь "то не знаю что" — но где же это взять.

Ну, естественно! Если бы я знал, что я хочу, то зачем мне тему по этому поводу создавать?

ЗЫ

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

Здравствуйте, VladD2, Вы писали:

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

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

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

Здравствуйте, VladD2, Вы писали:

VD>Но сама идея использовать игру в качестве примера — это хорошая идея. Игра — это почти всегда симуляция. А где есть симуляция, там ООП подходит отлично. Подумаю над этим вопросом.
С играми есть проблема. К ним еверты прикручивать некуда.
Но если таки делать игру думаю тут лучше всего подойдет стрелялка типа этой http://armorgames.com/play/1920/bubble-tanks-2

Здравствуйте, VladD2, Вы писали:

VD>1. Простенькая электронная табличка. Плюс в том, что в ней можно использовать строчный калькулятор из предыдущих частей.
Это плохой пример для ООП

Здравствуйте, frontsquat, Вы писали:

F>ООП к месту лишь в узком специализированном классе задач. Например, моделирование. Вряд ли это простой класс задач, подходящий для ваших целей. А в большинстве случаев ООП неуместно, криво, искусственно притянуто за уши. Поэтому лучше вообще не приводите пример с ООП.
Моделирование мира в игрушке вполне подходит.

Здравствуйте, VladD2, Вы писали:

VD>Классический пример чего? Ты видел как реально эти векторные редакторы делаются? Ни кто в жизни не додумается в реальном коде использовать ООП для векторной графики.

Ты в WPF то заглядывал ?

VD>Это как раз и есть пример того что хотелось бы избежать. Я же даже перечислил это в теме. Вторым (точнее первым) примером является иерархия животных. Кошка.Голос(), Собака.Голос(). Бррррр!

Ну например простой случай — синглпейн аутлайнер с фолдингом.

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

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

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

Здравствуйте, VladD2, Вы писали:

VD>Пока что есть две версии:
VD>1. Простенькая электронная табличка. Плюс в том, что в ней можно использовать строчный калькулятор из предыдущих частей.

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Mystic, Вы писали:

M>>Здравствуйте, VladD2, Вы писали:

VD>А вот с "Generic alpha-beta перебором" не знаком, к сожалению. В чем его прелесть?
VD>Имеется в виду вот это: http://en.wikipedia.org/wiki/Alpha-beta_pruning ?

Да, это. Но можно и полный перебор, будет чуть короче

VD>Играем в шахматы? Не круто ли для примера?

Да можно хоть крестики-нолики сделать. Основная задача выбрать две игры, чтобы их реализации хоть немного пересекались. Можно, например, крестики-нолики 3x3 взять, у Гарднера много вариантнов: обычные крестики-нолики, обратные крестики-нолики, где тот кто поставил три крестика или нолика в ряд, тот проиграл. Вариант, где каждый выставляет как крестики, так и нолики, задача одного игрока выиграть, другого сделать ничью. И т. д. и т. п.

Здравствуйте, VladD2, Вы писали:

VD>Прошу подкинуть идей примеров в процессе реализации которых можно было бы продемонстрировать основные концепции ООП, точнее элементы языка используемые для поддержки ООП (они в Nemerle такие же как в C#).

классические примеры ООП-иерархий: исключения, контейнеры (пример в STL), потоки в/в (кажись в delphi/vcl было наворочено), элементарные типы данных (как ни смешно, в хаскеле охрененная иерархия тайпклассов для чисел)

Здравствуйте, WolfHound, Вы писали:

WH>С играми есть проблема. К ним еверты прикручивать некуда.

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

Здравствуйте, VladD2, Вы писали:

VD>Цитирую себя любимого:
VD>

VD>Пример должен быть:
VD>* Кратким. Я должен легко описать его в рамках одной статьи (10-15) страниц (по 5 тысяч знаков без учета пробелов).
VD>* Он должен демонстрировать наследование, виртуальные методы, события. Хорошо бы, но не обязательно, чтобы он так же демонстрировал использование интерфейсов.
VD>* Понятным.
VD>* Не абстрактным и практичным. Меня самого всегда раздражало когда ООП подавали на совершенно не реалистичных примерах вроде построения иерархии животных или библиотеки графических примитивов (которые на практике никакого ООП не используют).
VD>* Возможно, но не обязательно, связан с примером строчного калькулятор.

Объявление в одном американском кафе.

Мы вас обслужим качественно, быстро и недорого. Выберите любые 2 из этих 3 требований.