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

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

I>Это отличный пример, а вот игрушка это отстой.

Брэк! И то, и то примеры. А отличные они или отстойные завист от моря деталей. Лично я пока не определился. Попробую оба варианта.

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

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

WH>Электронная таблица это функциональный язык.

Не. Это язык (очень примитивный), GUI которое позволяет этот язык применять и небольшая инфрастуктура.

Язык можно элементарно получить путем допиливания строчного калькулятора. Все что в нем нужно доделать — это добавить переменные, диапазоны и функции. Это не так сложно.

WH> Так что тут ООП вообще никак и ни о чем.

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

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

WH>А вот игрушка это симуляция игрового мира. Симуляция это единственная задача где ООП рулит.

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

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

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

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

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

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

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

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

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

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

K>А чем вышеупомянутое реактивное программирование хуже ООП для симуляции вообще и игр в частности?

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

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

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

Круги, эллипсы говорите? Это же как раз классический парадокс о невозможности наследования (то же, кстати, касается и прямоугольника-квадрата):
http://en.wikipedia.org/wiki/Circle-ellipse_problem


Т.е. если уж и строить пример с фигурами, то надо эту проблему либо явно упомянуть, либо искусно обойти

VladD2,

Есть широко известный в узких кругах пример машины для приготовления кофе:

http://alistair.cockburn.us/Coffee+machine+design+problem,+part+1
http://alistair.cockburn.us/Coffee+machine+design+problem,+part+2

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

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

Полученная в результате иерархия:

class Recipe   // Knows its ingredients and quantities
class Product  // Knows its price and recipe
class CashBox         // Knows credit available. Handles money or direct debit.
class ProductSelector // Knows products; Captures selection; Coordinates CashBox and Mixer.
class Mixer           // Interprets recipes; Coordinates dispensers.

class BlackCoffee subclass of Product 
class WhiteCoffee subclass of Product 
class BlackSugarCoffee subclass of Product 
class WhiteSugarCoffee subclass of Product 
class Bouillon subclass of Product 
class Moccha subclass of Product

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

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

Никакой связи с примером строчного калькулятора.

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

LCR>VladD2,

LCR>Полученная в результате иерархия:
LCR>

LCR>class Recipe   // Knows its ingredients and quantities
LCR>class Product  // Knows its price and recipe
LCR>class CashBox         // Knows credit available. Handles money or direct debit.
LCR>class ProductSelector // Knows products; Captures selection; Coordinates CashBox and Mixer.
LCR>class Mixer           // Interprets recipes; Coordinates dispensers.

LCR>class BlackCoffee subclass of Product 
LCR>class WhiteCoffee subclass of Product 
LCR>class BlackSugarCoffee subclass of Product 
LCR>class WhiteSugarCoffee subclass of Product 
LCR>class Bouillon subclass of Product 
LCR>class Moccha subclass of Product
LCR>

LCR>На мой взгляд весьма компактна (если что, можно выкинуть лишние виды кофе), есть наследование, полиморфизм, контейнер полиморфных объектов, события, интерфейсы. Насчёт практичности — пример основан на нормальных конкретных вещах, который каждый человек хотя бы раз трогал и видел в реальной жизни.

Такая иерархия:

class BlackCoffee subclass of Product 
class WhiteCoffee subclass of Product 
class BlackSugarCoffee subclass of Product 
class WhiteSugarCoffee subclass of Product

наводит на мысль, что нужно применить композицию, а не наследование.

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

VD>Пишу очередную (четвертую) часть Язык Nemerle.
VD>Данная часть должна быть посвящена ООП-у.
VD>К сожалению, в голову не приходит хороших идей для демонстрации ООП-а.

Тут неоднократно выражали точку зрения (по моему мнению — правильную), что в Немерле функциональная декомпозиция применяется "на уровне метода", а объектная декомпозиция "на более высоком уровне — для организации этих методов". Отсюда очевидная проблема: если демонстрировать ООП на базе небольшой простой задачи — эта демонстрация неизбежно окажется вмученной, а ООП там притянутым за уши. Ну, по той простой причине, что для решения "небольших задач" на Немерле ООП действительно не нужен. Читатель книги просто придет к выводу, что "ООП не нужен" — вот и все. Если такая цель и ставится, то самый простой способ ее достижения — решить ту же задачу с калькулятором средствами ООП и читатель отшатнется от ООП в ужасе. Если ставится противоположная задача, то и демонстрировать ООП нужно для решения проблем, для которых он в Немерле и предназначен: т.е. для организации более мелких задач, решенных с помощью ФП. В данном случае — строчного калькулятора. Поэтому электронная таблица в этом смыле кажется подходящим примером. Но с другой стороны, как верно было замечено, это не лучший для демонстрации ООП пример.
Другой пример, не связанный с использованием калькулятора, также будет представлять из себя несколько подзадач, решенных в функциональном стиле и связанных с помощью ООП. Т.е. глава про ООП будет по большей части состоять из демонстрации средств ФП — насколько это будет правильно в методическом плане?
Если это книга для обучения программированию, не лучше ли было бы рассматривать ООП в главе про высокоуровневую организацию программы — т.е. на решении тех задач, для которых оно в Немерле и предназначено, а не выдумывать какую-то вымученную проблему? Еще лучше — подвести по ходу книги читателя к проблемам дизайна "верхнего уровня", попытаться решить их средствами ФП, выделить возникшие сложности и после этого продемонстрировать ООП как средство их решения.
В противном случае у читателя неизбежно возникнет впечатление, что ООП совершенно излишне в Немерле и его средства добавлены в язык ни для чего, без всякого смысла.

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

LCR>VladD2,

LCR>Есть широко известный в узких кругах пример машины для приготовления кофе:

LCR>http://alistair.cockburn.us/Coffee+machine+design+problem,+part+1
LCR>http://alistair.cockburn.us/Coffee+machine+design+problem,+part+2

Статья аж 1998 года, когда hype ООП был на пике. Надеюсь сейчас такого никто не напишет, в том числе в предстоящей статье по Nemerle.

gandjustas,

G>Статья аж 1998 года, когда hype ООП был на пике. Надеюсь сейчас такого никто не напишет, в том числе в предстоящей статье по Nemerle.

Евклидова геометрия берёт своё начало почти 2500 лет назад, и ничего, мы все ей пользуемся. Так что претензия к дате не принимается. С чем ещё не согласен?

anton_t,

_>Такая иерархия:

_>

_>class BlackCoffee subclass of Product 
_>class WhiteCoffee subclass of Product 
_>class BlackSugarCoffee subclass of Product 
_>class WhiteSugarCoffee subclass of Product
_>

_>наводит на мысль, что нужно применить композицию, а не наследование.

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

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

LCR>gandjustas,

G>>Статья аж 1998 года, когда hype ООП был на пике. Надеюсь сейчас такого никто не напишет, в том числе в предстоящей статье по Nemerle.

LCR>Евклидова геометрия берёт своё начало почти 2500 лет назад, и ничего, мы все ей пользуемся. Так что претензия к дате не принимается. С чем ещё не согласен?

А причем тут возраст? В 1998 году было модно писать такой код, сейчас большинство разработчиков понимают что он не нужен.

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

gandjustas,

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

Тогда уж сразу — иерархии не нужны! Интерфейсы + реализация = и все щасливы (вкупе с mixin composition даже я). А пример я и не предлагал копипэстить — его можно и нужно адаптировать. Наделить Product каким нибудь поведением, скажем getPrice. Там ведь ещё бульон есть, ты заметил это?

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

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

+1! Эрланг — самый правильный ОО язык.

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

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

У меня нет задачи объяснить людям что такое ООП. Моя задача показать как фичи ООП можно использовать для написания реальной программы.

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

LCR>Полученная в результате иерархия:
LCR>

LCR>class Recipe   // Knows its ingredients and quantities
LCR>class Product  // Knows its price and recipe
LCR>class CashBox         // Knows credit available. Handles money or direct debit.
LCR>class ProductSelector // Knows products; Captures selection; Coordinates CashBox and Mixer.
LCR>class Mixer           // Interprets recipes; Coordinates dispensers.

LCR>class BlackCoffee subclass of Product 
LCR>class WhiteCoffee subclass of Product 
LCR>class BlackSugarCoffee subclass of Product 
LCR>class WhiteSugarCoffee subclass of Product 
LCR>class Bouillon subclass of Product 
LCR>class Moccha subclass of Product
LCR>

LCR>На мой взгляд весьма компактна (если что, можно выкинуть лишние виды кофе), есть наследование, полиморфизм, контейнер полиморфных объектов, события, интерфейсы. Насчёт практичности — пример основан на нормальных конкретных вещах, который каждый человек хотя бы раз трогал и видел в реальной жизни.

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

Но, все равно, спасибо за ссылку. Рассмотрю и этот вариант.

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

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

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

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

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

L>+1! Эрланг — самый правильный ОО язык.

Дык медленный очень.

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

На базе самого Немерле. А именно его компилятора.
Скажем AST это дерево структур типа Unary/BinaryExpression ну и т.д.

И людям полезно будет въехать в конструкцию AST ибо Nemerle как я понимаю
позволяет работать с ним.