|
|
|
Возраст: 35  
C нами с 04.02.2005
Репутация: 121.3  
|
|
Ну, в C++ есть еще typeinfo. Будет достаточно в контейнере реализовать механизм [псевдо]итераторов, и никаких проблем с проектированием базового класса не будет.
Ну а если без typeinfo, можно сделать метод типа "get_fruit_type" и присвоить каждому виду фруктов свой номер.
|
|
|
|
|
|
|
 |
|
|
|
C нами с 09.06.2005
Репутация: 548.7
|
|
chaser, это все тоже фейк... Любая конструкция типа if(e.IsA()), или if(e.getType()==e.Type), или if(e is Type) - все это криво... Уж лучше выносить алгоритмы за пределы класса и виртуальными методами создавать объекты-процессоры для каждого типа фруктов. Паттерн не вспомню, книжку кому-то дал почитать... 
|
|
|
|
|
|
|
|
|
|
|
Возраст: 35
C нами с 04.02.2005
Репутация: 121.3
|
|
Ну понятно, что в идеале виртуальные функции должны заниматься такими делами. "Все это криво" — все-таки не исчерпывающее объяснение, почему так делать не стоит. Про isApple(), isOrange() и т.п. я безусловно соглашусь — это в любом случае кривая архитектура.
Но о getType() — вдруг иногда все-таки нужно? Вдруг программа будет столь специфической, что это будет наиболее приемлимым вариантом? Typeinfo с dynamic_cast'ом, наверное, не просто так в C++ добавили (я не пользовался, правда, ими ни разу).
Алгоритм, кстати, в предложенном мной способе предполагается реализовать отдельной шаблонной функцией.
|
|
|
|
|
|
|
|
|
|
|
C нами с 09.06.2005
Репутация: 548.7
|
|
typeinfo мне тоже не пришлось использовать почему-то, что уже забавно, что нам обоим это не понадобилось...  Видимо, есть варианты обойтись без него обычно. Потому и считаю, что криво, раз есть пути обхода. Как ни крути, но это имеет ограниченное применение, некий частный случай. Любой новый класс в иерархии вполне вероятно потребует модификации такого кода. А если он разбросан по большому проекту? Тогда все это превращается в большой геморрой!
|
|
|
|
|
|
|
|
|
|
|
C нами с 25.01.2005
Репутация: 97.3
|
|
продолжение ;)
в ресторане есть склад, на котором хранятся фрукты
в ресторане работает повар, который умеет готовить фруктовые салаты по известным рецептам
рецепт прост:
для приготовления фруктового салата вам понадобятся 3 яблока и 2 груши
все это помыть, почистить и нарезать
перемешать и охладить
помогите грамотно реализовать на ООП без использования фэйка? ;)
|
|
|
|
|
|
|
|
|
|
|
C нами с 09.06.2005
Репутация: 548.7
|
|
Склад - объект-фабрика, умеющая производить некое ограниченное количество объектов-фруктов, т.е. объектов классов Яблоко, Груша и т.д., реализующих общий интерфейс Фрукт. Типа, получитьЯблоко(кол-во) и т.д. На кухне есть объект-фруктопроцессор, который имеет методы нарезать(Фрукт), помыть(Фрукт) и т.д., которые в результате выдают набор (массив, список, кучу) объектов-кусочков. Этот набор (заметьте, уже не важно кусочков какого именно фрукта или овоща!) передается в объект миксер, а оттуда в объект-холодильник. Т.е. вся специфика и типозависимость алгоритма прячется в один-единственный метод, инкапсулирующий вызовы Склад, производящие фрукты и овощи в нужном количестве и помещающий их в соответсвующие процессоры. Потом уже различий не существует, мешалке и холодильнику не важно что и в каком количестве мешать...
PS: тут еще сделано предположение, что фрукторезка и фруктомойка это специализированные процессоры. Допустим, они не столь жестоко обращаются с объектами резки/мойки, нежели овощерезки/овощемойки, например. А ведь можно и совместить фрукты с овощами. Можно продолжать и дальше: можно завести объект-салат, который содержит в себе метод, реализующий этот самый процесс получения ингридиентов в нужном количестве. Сумбурно, правда все тут. Роли распределены через задницу, но для примера сойдет... 
|
|
|
|
|
|
|
|
|
|
|
C нами с 25.01.2005
Репутация: 97.3
|
|
про кухню ты здорово написал ;)
проблема заключается в том, как реализовать склад
сам по себе склад не может производить фрукты, ресторан закупает фрукты у поставщика
таким образом, прежде чем повар сможет взять конкретный фрукт со склада, его туда должен положить поставщик или управляющий складом
управляющий складом следит (перидически проверяет) за тем, чтобы на складе был достаточный запас фруктов разных типов
управляющий складом анализирует, сколько съедено, сколько осталось, сколько каких фруктов нужно заказать, чтобы хватило до следующей закупки
дальше он составляет перечень покупок и делает заказ
|
|
|
|
|
|
|
|
|
|
|
C нами с 09.06.2005
Репутация: 548.7
|
|
А понятие "абстракция" зачем в ООП существует? Вот я от всего этого и абстрагировался в соответсвии с поставленной задачей!
Позже придумаем и остальное. Вот только зачем оно надо? Кухня была иллюстрацией способа. Не буду же я всю архитектуру на халяву в качестве примера строить! 
PS: Может проще взять книжку Гр. Буча "Объектно-ориентированное проектирование" и книжку Банды 4-х "Паттерны проектирования" и все все прочитать самому?
|
|
|
|
|
|
|
|
|
|
|
Возраст: 39 
C нами с 04.05.2006
Репутация: 63.9
|
|
| Madlax писал(а): |
есть фрукты: яблоки, груши и апельсины
есть корзинка, в которой хранятся фрукты
после того, как в корзинку сложены разные фрукты, из нее невозможно достать одни только яблоки
то есть в идеальной ООП клиент видит все объекты в корзинке как фрукты и не может отлечить яблоки от груш
кто знает, как решается?
|
Честно говоря проблемы не увидел
Очень просто решается...
Создается класс корзина. У класса несколько свойств:
Коллекция объектов "яблоко", коллекция "груши", коллекция мандаринов итп. Нужно нам определить вес яблока, пишем к примеру
float Весяблока = Korzina.AppleCollection[0].AppleWeight;
Вот и все...
|
|
|
|
|
|
|
|
|
|
|
Возраст: 35
C нами с 04.02.2005
Репутация: 121.3
|
|
Petro, ну, это, простите, не очень тянет на ООП. Больше похоже на C без суффикса "плюс плюс" 
| MajorQ писал(а): |
|
Видимо, есть варианты обойтись без него обычно. Потому и считаю, что криво, раз есть пути обхода.
|
Здесь с тезисом "криво, раз есть пути обхода" не могу согласиться. Ведь так можно отказаться, например, и от классов. Пример тому — семейство библиотек GTK+/Glib/Gobject, написанное на C. В них происходит "эмуляция" ООП — пользователь динамически регистрирует класс и т.д. С помощью указателей на функции реализован полиморфизм. На самом деле, ужасная вещь, если глубоко ковырять. (Если интересно, домашняя страница — http://gtk.org, исходники можно скачать у нас в сети).
|
|
|
|
|
|
|
|
|
|
|
C нами с 09.06.2005
Репутация: 548.7
|
|
|
chaser, я, конечно, выразился криво... Имел ввиду, что все эти typeinfo не вписываются в концепцию "трех китов ООП": абстракция, инкапсуляция, полиморфизм. Сугубо ИМХО, но динамическая информация о типе - это костыли для неумелых проектировщиков...
|
|
|
|
|
|
|
|
|
|
|
Возраст: 35
C нами с 04.02.2005
Репутация: 121.3
|
|
|
MajorQ, если RTTI используется при изначальном проектировании — да, это скорее костыли, здесь я соглашусь. А что, если есть готовая библиотека, которую надо использовать, но уже нельзя перепроектировать? Кстати, рассуждения по этому поводу можно найти в 14-ой главе "Дизайна и эволюции" — очень рекомендую.
|
|
|
|
|
|
|
|
|
|
|
Возраст: 39
C нами с 04.05.2006
Репутация: 63.9
|
|
| chaser писал(а): |
|
Petro, ну, это, простите, не очень тянет на ООП. Больше похоже на C без суффикса "плюс плюс"
|
chaser, Если коллекция объектов это не ООП, тогда чтоже это? ))
Корзина - объект, фрукт - объект, яблоко объект унаследованный от фрукт..
P.S. А причем тут плюсы? Мыже вроде об ООП говорим как концепции... Пример кстати на С#
|
|
|
|
|
|
|
|
|
|
|
C нами с 09.06.2005
Репутация: 548.7
|
|
|
Petro, коллекция объектов это еще не ООП. Про "три столпа" я уже написал. В коллекции от них есть только один - инкапсуляция. Советую у Буча вчитаться в их объяснение и хорошенько понять их...
|
|
|
|
|
|
|
|
|
|
|
Возраст: 39
C нами с 04.05.2006
Репутация: 63.9
|
|
| MajorQ писал(а): |
|
Petro, коллекция объектов это еще не ООП. Про "три столпа" я уже написал. В коллекции от них есть только один - инкапсуляция. Советую у Буча вчитаться в их объяснение и хорошенько понять их...
|
MajorQ, Тогда как получается, что если в коде нету чего-то одного (инкапсуляции, наследования или полиморфизма), то программа не считается объектно ориентированной?!
ООП не должен быть ради ООПа... Если есть задача, её надо решать исходя из здравого смысла. Можно сделать все методы виртуальными и говорить, что мой код офигенно полиморфный... только толку от этого не будет.
|
|
|
|
|
|
|
|
| |
|
|
