Здравствуйте, Ikemefula, Вы писали:
VD>>>1. Простенькая электронная табличка. Плюс в том, что в ней можно использовать строчный калькулятор из предыдущих частей. WH>>Это плохой пример для ООП
I>Это отличный пример, а вот игрушка это отстой.
Брэк! И то, и то примеры. А отличные они или отстойные завист от моря деталей. Лично я пока не определился. Попробую оба варианта.
Проблема в том, что если как должен выглядеть грид-ёксель я знаю, то игрушки для меня тема не раскрытая. Нужен хороший пример.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: На базе чего лучше всего продемонстрировать ООП?
Здравствуйте, WolfHound, Вы писали:
WH>Электронная таблица это функциональный язык.
Не. Это язык (очень примитивный), GUI которое позволяет этот язык применять и небольшая инфрастуктура.
Язык можно элементарно получить путем допиливания строчного калькулятора. Все что в нем нужно доделать — это добавить переменные, диапазоны и функции. Это не так сложно.
WH> Так что тут ООП вообще никак и ни о чем.
Ну, как же? Это о том, как в грид вводить данные, как их отображать и как их извлекать (записывать в файл).
Отображение и ввод (пользовательский) — это весьма себе симуляционная задачка. Сам спред — объект наследуемый от базового класса — грида. Ему нужно будет поменять поведение, так чтобы он отображал одно (значения), а редактировал другое (формулы). Пока не знаю насколько удастся продемонстрировать переопределение методов и другие ОО-фичи. Но в целом может получиться.
WH>А вот игрушка это симуляция игрового мира. Симуляция это единственная задача где ООП рулит.
Согласен. Но и там симуляция интерфейса. Причем значительно более простая. А это может оказаться хорошо для примера. Хотя может и плохо, если не удастся впихнуть в пример основные фичи ООП-а.
Что же касается игрушек, то тут есть одна проблема. Я их никогда не писал. Теоретически я конечно представляю как это все должно выглядеть, но практически я даже не знаю как оценить объем кода для некоторой игршки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: На базе чего лучше всего продемонстрировать ООП?
Здравствуйте, VladD2, Вы писали:
VD>Проблема в том, что если как должен выглядеть грид-ёксель я знаю, то игрушки для меня тема не раскрытая. Нужен хороший пример.
Ну, давай тогда грид, желательно в виде компонента, шоб заюзать было очнь просто
Re: На базе чего лучше всего продемонстрировать ООП?
Здравствуйте, VladD2, Вы писали:
VD>Пишу очередную (четвертую) часть Язык Nemerle. VD>Данная часть должна быть посвящена ООП-у.
VD>К сожалению, в голову не приходит хороших идей для демонстрации ООП-а.
ООП не очень хорошо демонстрировать на наследовании. Скорее подойдет некая модель, где будет 2 или больше интерактивно общающихся объекта. Суть ООП лучше всего видна во взаимодействующих объектах с инкапсулированным состоянием.
Re[13]: На базе чего лучше всего продемонстрировать ООП?
Здравствуйте, Куть, Вы писали:
К>Классический пример: векторный редактор — круги, прямоугольники, эллипсы. Переопределяется рисование, изменение масштаба, повороты и т.д. В базовом классе, например, перемещение.
На этом примере автор демонстрирует не только возможности ООП, но и некоторые подводные камни, которые появляются если ринуться с шашкой наголо.
VD>Пример должен быть: VD>* Кратким. Я должен легко описать его в рамках одной статьи (10-15) страниц (по 5 тысяч знаков без учета пробелов). VD>* Он должен демонстрировать наследование, виртуальные методы, события. Хорошо бы, но не обязательно, чтобы он так же демонстрировал использование интерфейсов. VD>* Понятным. VD>* Не абстрактным и практичным. Меня самого всегда раздражало когда ООП подавали на совершенно не реалистичных примерах вроде построения иерархии животных или библиотеки графических примитивов (которые на практике никакого ООП не используют).
Полученная в результате иерархия:
classRecipe// Knows its ingredients and quantitiesclassProduct// Knows its price and recipeclassCashBox// Knows credit available. Handles money or direct debit.classProductSelector// Knows products; Captures selection; Coordinates CashBox and Mixer.classMixer// Interprets recipes; Coordinates dispensers.classBlackCoffee subclass of ProductclassWhiteCoffee subclass of ProductclassBlackSugarCoffee subclass of ProductclassWhiteSugarCoffee subclass of ProductclassBouillon subclass of ProductclassMoccha subclass of Product
На мой взгляд весьма компактна (если что, можно выкинуть лишние виды кофе), есть наследование, полиморфизм, контейнер полиморфных объектов, события, интерфейсы. Насчёт практичности — пример основан на нормальных конкретных вещах, который каждый человек хотя бы раз трогал и видел в реальной жизни.
VD>* Возможно, но не обязательно, связан с примером строчного калькулятор.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>VladD2,
LCR>Полученная в результате иерархия: LCR>
LCR>classRecipe// Knows its ingredients and quantities
LCR>classProduct// Knows its price and recipe
LCR>classCashBox// Knows credit available. Handles money or direct debit.
LCR>classProductSelector// Knows products; Captures selection; Coordinates CashBox and Mixer.
LCR>classMixer// Interprets recipes; Coordinates dispensers.
LCR>classBlackCoffee subclass of Product
LCR>classWhiteCoffee subclass of Product
LCR>classBlackSugarCoffee subclass of Product
LCR>classWhiteSugarCoffee subclass of Product
LCR>classBouillon subclass of Product
LCR>classMoccha 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
наводит на мысль, что нужно применить композицию, а не наследование.
Re: На базе чего лучше всего продемонстрировать ООП?
Здравствуйте, VladD2, Вы писали:
VD>Пишу очередную (четвертую) часть Язык Nemerle. VD>Данная часть должна быть посвящена ООП-у. VD>К сожалению, в голову не приходит хороших идей для демонстрации ООП-а.
Тут неоднократно выражали точку зрения (по моему мнению — правильную), что в Немерле функциональная декомпозиция применяется "на уровне метода", а объектная декомпозиция "на более высоком уровне — для организации этих методов". Отсюда очевидная проблема: если демонстрировать ООП на базе небольшой простой задачи — эта демонстрация неизбежно окажется вмученной, а ООП там притянутым за уши. Ну, по той простой причине, что для решения "небольших задач" на Немерле ООП действительно не нужен. Читатель книги просто придет к выводу, что "ООП не нужен" — вот и все. Если такая цель и ставится, то самый простой способ ее достижения — решить ту же задачу с калькулятором средствами ООП и читатель отшатнется от ООП в ужасе. Если ставится противоположная задача, то и демонстрировать ООП нужно для решения проблем, для которых он в Немерле и предназначен: т.е. для организации более мелких задач, решенных с помощью ФП. В данном случае — строчного калькулятора. Поэтому электронная таблица в этом смыле кажется подходящим примером. Но с другой стороны, как верно было замечено, это не лучший для демонстрации ООП пример.
Другой пример, не связанный с использованием калькулятора, также будет представлять из себя несколько подзадач, решенных в функциональном стиле и связанных с помощью ООП. Т.е. глава про ООП будет по большей части состоять из демонстрации средств ФП — насколько это будет правильно в методическом плане?
Если это книга для обучения программированию, не лучше ли было бы рассматривать ООП в главе про высокоуровневую организацию программы — т.е. на решении тех задач, для которых оно в Немерле и предназначено, а не выдумывать какую-то вымученную проблему? Еще лучше — подвести по ходу книги читателя к проблемам дизайна "верхнего уровня", попытаться решить их средствами ФП, выделить возникшие сложности и после этого продемонстрировать ООП как средство их решения.
В противном случае у читателя неизбежно возникнет впечатление, что ООП совершенно излишне в Немерле и его средства добавлены в язык ни для чего, без всякого смысла.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[2]: На базе чего лучше всего продемонстрировать ООП?
gandjustas,
G>Статья аж 1998 года, когда hype ООП был на пике. Надеюсь сейчас такого никто не напишет, в том числе в предстоящей статье по Nemerle.
Евклидова геометрия берёт своё начало почти 2500 лет назад, и ничего, мы все ей пользуемся. Так что претензия к дате не принимается. С чем ещё не согласен?
_>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 году было модно писать такой код, сейчас большинство разработчиков понимают что он не нужен.
Иерархии без полиморфного поведения не нужны. Декомпозиция должна быть не на основе физических объектов, а на основе выполняемых действий.
Re[5]: На базе чего лучше всего продемонстрировать ООП?
gandjustas,
G>Иерархии без полиморфного поведения не нужны. Декомпозиция должна быть не на основе физических объектов, а на основе выполняемых действий.
Тогда уж сразу — иерархии не нужны! Интерфейсы + реализация = и все щасливы (вкупе с mixin composition даже я). А пример я и не предлагал копипэстить — его можно и нужно адаптировать. Наделить Product каким нибудь поведением, скажем getPrice. Там ведь ещё бульон есть, ты заметил это?
Здравствуйте, vdimas, Вы писали:
V>ООП не очень хорошо демонстрировать на наследовании. Скорее подойдет некая модель, где будет 2 или больше интерактивно общающихся объекта. Суть ООП лучше всего видна во взаимодействующих объектах с инкапсулированным состоянием.
+1! Эрланг — самый правильный ОО язык.
Re[2]: На базе чего лучше всего продемонстрировать ООП?
Здравствуйте, vdimas, Вы писали:
V>ООП не очень хорошо демонстрировать на наследовании. Скорее подойдет некая модель, где будет 2 или больше интерактивно общающихся объекта. Суть ООП лучше всего видна во взаимодействующих объектах с инкапсулированным состоянием.
У меня нет задачи объяснить людям что такое ООП. Моя задача показать как фичи ООП можно использовать для написания реальной программы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: На базе чего лучше всего продемонстрировать ООП?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Полученная в результате иерархия: LCR>
LCR>classRecipe// Knows its ingredients and quantities
LCR>classProduct// Knows its price and recipe
LCR>classCashBox// Knows credit available. Handles money or direct debit.
LCR>classProductSelector// Knows products; Captures selection; Coordinates CashBox and Mixer.
LCR>classMixer// Interprets recipes; Coordinates dispensers.
LCR>classBlackCoffee subclass of Product
LCR>classWhiteCoffee subclass of Product
LCR>classBlackSugarCoffee subclass of Product
LCR>classWhiteSugarCoffee subclass of Product
LCR>classBouillon subclass of Product
LCR>classMoccha subclass of Product
LCR>
LCR>На мой взгляд весьма компактна (если что, можно выкинуть лишние виды кофе), есть наследование, полиморфизм, контейнер полиморфных объектов, события, интерфейсы. Насчёт практичности — пример основан на нормальных конкретных вещах, который каждый человек хотя бы раз трогал и видел в реальной жизни.
Есть большое подозрение, что на вариантных типах (алгебраических типах) эту задачу будет намного удобнее описывать. Иерархия с одним родителем намекает на это.
Но, все равно, спасибо за ссылку. Рассмотрю и этот вариант.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: На базе чего лучше всего продемонстрировать ООП?
Здравствуйте, Klapaucius, Вы писали:
K>...Если это книга для обучения программированию, не лучше ли было бы рассматривать ООП в главе про высокоуровневую организацию программы — т.е. на решении тех задач, для которых оно в Немерле и предназначено, а не выдумывать какую-то вымученную проблему? Еще лучше — подвести по ходу книги читателя к проблемам дизайна "верхнего уровня", попытаться решить их средствами ФП, выделить возникшие сложности и после этого продемонстрировать ООП как средство их решения. K>В противном случае у читателя неизбежно возникнет впечатление, что ООП совершенно излишне в Немерле и его средства добавлены в язык ни для чего, без всякого смысла.
Мысли правильные, но к сожалению действительно сложную задачу в обучающих целях использовать нельзя. Люди просто запутаются.
В принципе электронная таблица будет как раз довольно большим примером, так что на ее базе наверно удастся продемонстрировать и аспект структуризации программы. Надо будет подумать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: На базе чего лучше всего продемонстрировать ООП?