Всем привет.

Пишу очередную (четвертую) часть Язык Nemerle.
Данная часть должна быть посвящена ООП-у.

К сожалению, в голову не приходит хороших идей для демонстрации ООП-а.

Во второй и третьей части в основном разбиралась написание кода в функциональном стиле на базе примера "строчный калькулятор". Калькулятор в этих частях был консольным приложением. Логика калькулятора была написана практически полностью в функциональном стиле.

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

using System.Windows.Forms;
using System.Drawing;

module Program
{
  Main() : void
  {
    def form               = Form();
    def expressionComboBox = ComboBox();
    def calculateButton    = Button();
    def resultTextBox      = TextBox();
    
    expressionComboBox.TabIndex  = 0;
    expressionComboBox.Bounds    = Rectangle(10, 10, 330, 30);
    
    calculateButton.AutoSize     = true;
    calculateButton.AutoSizeMode = AutoSizeMode.GrowAndShrink;
    calculateButton.TabIndex     = 1;
    calculateButton.Text         = "Calculate";
    calculateButton.Location     = Point(350, 10);
    
    resultTextBox.Location       = Point(10,  40);
    resultTextBox.Width          = calculateButton.Right - 20;
    resultTextBox.TabIndex       = 2;
    
    form.AcceptButton            = calculateButton;
    form.Text                    = "Calculator";

    form.Controls.Add(resultTextBox);
    form.Controls.Add(calculateButton);
    form.Controls.Add(expressionComboBox);

    form.ClientSize = Size(calculateButton.Right + 10, 
                           resultTextBox.Top + resultTextBox.Height + 10);
    
    calculateButton.Click += 
      fun(_, _)
      {
        def text = expressionComboBox.Text;
        def calc = CalcParser();
        
        def updateHistoryList()
        {
          def index = expressionComboBox.Items.IndexOf(text);
          
          when (index >= 0)
          {
            expressionComboBox.Items.RemoveAt(index);
            expressionComboBox.Text = text;
          }
            
          expressionComboBox.Items.Insert(0, text);
        }
        
        updateHistoryList();
        
        match (calc.ParseAndEval(text))
        {
          | Some(val) => resultTextBox.Text = val.ToString();
          | None      =>
            def (pos, msg) = calc.Error;
            
            resultTextBox.Text = msg;
            
            when (pos >= 0)
            {
              expressionComboBox.SelectionStart = pos;
              expressionComboBox.SelectionLength = 1;
              expressionComboBox.Select();
            }
        }
      };
    
    Application.EnableVisualStyles();
    Application.Run(form);
  }
}

Тут даже наследование не потребовалось (дизайнер форм им пользуется, но смысла в это — ноль).

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

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

Одной из идей предложенной Воронковым было разработать электронную таблицу (аля сильно упрощенный Exel). Но боюсь, что это будет перебор.

Первое что пришло в голову из реальных проектов:
1) Сохранение отчетов в разных форматах: например в Excel, xml, html.
2) Переопределение методов вида OnSomeEvent(...)
3) Создание кастомных коллекций, типа ReadOnlyBindingList и т.д.
4) Базовый класс объектов предметной области, предоставляющий какую-то базовую функциональность, а уже унаследованные объекты перегружают методы типа Validate() и т.д.
5) Можно взять пример из BLT — базовый класс DataProviderBase и уже конкретные реализации провайдеров СУБД — MySqlDataProvider, OracleDataProvider и др., которые переопределяеют методы типа CreateConnectionObject и т.д.

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

MC>Первое что пришло в голову из реальных проектов:
MC>1) Сохранение отчетов в разных форматах: например в Excel, xml, html.

Каких отчетов? Где их взять. Материал рассчитан как минимум на новичков в языке. А по уму на новичков в программировании.

MC>2) Переопределение методов вида OnSomeEvent(...)
MC>3) Создание кастомных коллекций, типа ReadOnlyBindingList и т.д.

Это как раз задачи ради задач. Ничему хорошему на таких примерах не научишь. Я еще раз подчеркиваю, что нужны законченные, просты, понятные и (желательно) полезные примеры.

MC>4) Базовый класс объектов предметной области, предоставляющий какую-то базовую функциональность, а уже унаследованные объекты перегружают методы типа Validate() и т.д.

И что за предметная область? Что-то связанное с БД и учетом на предприятиях? Дык сначала придется всю подноготную придумывать и описывать.

MC>5) Можно взять пример из BLT — базовый класс DataProviderBase и уже конкретные реализации провайдеров СУБД — MySqlDataProvider, OracleDataProvider и др., которые переопределяеют методы типа CreateConnectionObject и т.д.

Примеры должны быть независимыми. Как можно объяснить ООП на базе огромных и сложных библиотек основанных на разных хитрых технологиях вроде деревьев выражений.

Пример с БД — идея не плохая, но не для части в которой дается ООП.

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

VD>На базе чего лучше всего продемонстрировать ООП?

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

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

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

BZ>на базе хаскела. дать человек прочитать gentle introduction и затем сказать: ну, теперь ты понял, сынок, какая херня получаются когда люди пытаются обойтись без классов?

Смешно! Вот только форум не "Коллеги улыбнитесь"

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

К>Классический пример: векторный редактор — круги, прямоугольники, эллипсы. Переопределяется рисование, изменение масштаба, повороты и т.д. В базовом классе, например, перемещение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И тем не менее, есть HotDraw by Kent Beck & Ward Cunningham. Я естественно допускаю, что нечто написанное в середине 80-х и без Nemerle не может служить примером объектной-ориентированности, но люди его на патерны разбирали (и тот текст всё еще можно найти).

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

VD>Смешно! Вот только форум не "Коллеги улыбнитесь"

а ты на работе и не улыбаешься вовсе поскольку пришёл туда работать?

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

ANS>И тем не менее, есть HotDraw by Kent Beck & Ward Cunningham. Я естественно допускаю, что нечто написанное в середине 80-х и без Nemerle не может служить примером объектной-ориентированности, но люди его на патерны разбирали (и тот текст всё еще можно найти).

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

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

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

D>Я написал один такой редактор для диаграмм. И ничего. Там ООП. Очень удобно для разделения логики.

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

ООП нужен там где есть симуляция чего-то. Вот в том же WPF ООП к месту. Но только на верхнем уровне, а внизу (где та самая графика), там к месту процедурная реализация.

D>Тут, наверное, надо смотреть на особенности мышления конкретного человека. Кого-то тошнит от примеров с числами Фибоначчи.

Ага. Меня, например.

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

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

D> Так и с примером наследования для фигур. Кому-то нравятся. Кому-то нет. Меня, например, слегка бесят примеры, перегруженные, как правило, чужой и чуждой мне "практикой".

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

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

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

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

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

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

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

любая форма
-диалог запроса
-форма с источником данных
--то же + data grid
--то же плюс кнопки ok/cancel/apply/undo для ред-ния одной записи

только там больше было, штук 10-20

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

VD>>Смешно! Вот только форум не "Коллеги улыбнитесь"

BZ>а ты на работе и не улыбаешься вовсе поскольку пришёл туда работать?

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

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

BZ>>а ты на работе и не улыбаешься вовсе поскольку пришёл туда работать?

VD>Улыбаюсь иногда.

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

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

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

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

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

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

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

Получаем примерно следующее:
интерфейс IGame, в котором реализуется NewGame, DoMove, [UndoMove,] GenMoves, State
абстрактный класс TGame8x8 (игра на доске 8x8 или около того)
классы TChess, TDraught, ...
класс TAlphaBetaEngine, который реализует alpha+beta перебор, и в котором есть куча event-ов на те или иные события, связанные с визуализацией поиска: изменение текущего хода, глубина, процент, ...

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

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

и получится банальное делегирование которое подходит и под ФП, и под банальные указатели на функции