Есть суперкласс Izdelie. (базовый для всех изделий). У всех изделий есть следующие атрибуты:
1) long ID; //Уникальный код изделия
2) string FullName; //Полное наименование материала
3) decimal Mass; //Масса изделия
4) Purchased; // Признак того, что изделие покупное
Изделия могут менять признак с ПОКУПНОЕ на СОБСТВЕННОЕ ИЗГОТОВЛЕНИЕ (и наоборот)
Если издлеия являются покупными, то у них имеются атрибуты ( Buyer — закупщик, Price — цена). Наоборот, изделия собственного производства, таких атрибутов у него нет.
С ДРУГОЙ СТОРОНЫ
Все изделия деляться на две группы (СОБСТВЕННОГО ПРОЕКТИРОВАНИЯ и ЧУЖОГО ПРОЕКТИРОВАНИЯ).
Изделия собственного проектирования (в отличии от чужих) имеют атрибут НОМЕР ЧЕРТЕЖА и ФАМИЛИЯ РАЗРАБОТЧИКА.
Здравствуйте, Kostyan2204, Вы писали: K>Как это реализовать?
Один из вариантов
class IProduction
{
};
class IPurchased : public IProduction
{
....
}
class ISelfMade : public IProduction
{
....
}
class IDesign
{
...
}
class IForeignDesign : public IDesign
{
....
}
class ISelfDesign : public IDesign
{
}
class Izdelie
{
IDesign* design;
IProduction * production;
}
Здравствуйте, Kostyan2204, Вы писали:
K>Приветствую!
K>Помогите разобраться с проблемой проектирования.
K>Есть суперкласс Izdelie. (базовый для всех изделий). У всех изделий есть следующие атрибуты: K>1) long ID; //Уникальный код изделия K>2) string FullName; //Полное наименование материала K>3) decimal Mass; //Масса изделия K>4) Purchased; // Признак того, что изделие покупное
K>Изделия могут менять признак с ПОКУПНОЕ на СОБСТВЕННОЕ ИЗГОТОВЛЕНИЕ (и наоборот)
K>Если издлеия являются покупными, то у них имеются атрибуты ( Buyer — закупщик, Price — цена). Наоборот, изделия собственного производства, таких атрибутов у него нет.
K>С ДРУГОЙ СТОРОНЫ K>Все изделия деляться на две группы (СОБСТВЕННОГО ПРОЕКТИРОВАНИЯ и ЧУЖОГО ПРОЕКТИРОВАНИЯ). K>Изделия собственного проектирования (в отличии от чужих) имеют атрибут НОМЕР ЧЕРТЕЖА и ФАМИЛИЯ РАЗРАБОТЧИКА.
K>Как это реализовать?
а сделать абстрактный класс изделие и 2-х наследников от него тебе не удобно?
а ссылку на изделие реализовать как ссылку на абстрактный класс, а если нужно вызывать специфические функции приводить его к одному из наследников.
естественно тебе потребуется какой-то енумовский мембер который будет говорить какое это изделие. по нему можно будет ориентироваться.
либо сделать проще. не делать абстрактных классов а сделать один класс изделия который будет включать в себя поля характерные как для одного типа изделий так и для другого. это менее красиво зато проще.
на чем пишешь?
Здравствуйте, apilikov, Вы писали:
A>а сделать абстрактный класс изделие и 2-х наследников от него тебе не удобно?
Возможно. Хотелось бы выслушать все варианты.
Разрабатываемая система будет являться хранилищем материалов, стандартных изделий и изделий собственного производства. Данные из неё должны будут использоваться в ERP-системе, а также в конструкторских спецификациях и технологических ведомостях.
(вобщем единое хранилище).
Может у вас есть ссылки на эту тему?
Интересуют восновном реализации (а не идея).
A>а ссылку на изделие реализовать как ссылку на абстрактный класс, а если нужно вызывать специфические функции приводить его к одному из наследников. A>естественно тебе потребуется какой-то енумовский мембер который будет говорить какое это изделие. по нему можно будет ориентироваться. A>либо сделать проще. не делать абстрактных классов а сделать один класс изделия который будет включать в себя поля характерные как для одного типа изделий так и для другого. это менее красиво зато проще.
A>на чем пишешь?
Пишу на C# 2.0
Здравствуйте, Kostyan2204, Вы писали:
K>Здравствуйте, apilikov, Вы писали:
A>>а сделать абстрактный класс изделие и 2-х наследников от него тебе не удобно?
K>Возможно. Хотелось бы выслушать все варианты.
K>Разрабатываемая система будет являться хранилищем материалов, стандартных изделий и изделий собственного производства. Данные из неё должны будут использоваться в ERP-системе, а также в конструкторских спецификациях и технологических ведомостях. K>(вобщем единое хранилище).
K>Может у вас есть ссылки на эту тему? K>Интересуют восновном реализации (а не идея).
A>>а ссылку на изделие реализовать как ссылку на абстрактный класс, а если нужно вызывать специфические функции приводить его к одному из наследников. A>>естественно тебе потребуется какой-то енумовский мембер который будет говорить какое это изделие. по нему можно будет ориентироваться. A>>либо сделать проще. не делать абстрактных классов а сделать один класс изделия который будет включать в себя поля характерные как для одного типа изделий так и для другого. это менее красиво зато проще.
A>>на чем пишешь? K>Пишу на C# 2.0
везет тебе. ну так что скажешь по поводу написанного выше?
Здравствуйте, Kostyan2204, Вы писали:
K>Здравствуйте, apilikov, Вы писали:
A>>везет тебе. ну так что скажешь по поводу написанного выше?
K>Большое спасибо за предложенные варианты
K>Ещё подумаю немного, определюсь, потом скажу (и результат покажу )
K>P.S. А чем мне везёт?
Как я понял из Вашего описания, каждое изделие должно быть:
Спроектировано. Изготовлено.
И сохранено и учтено в Вашей базе данных.
Исходя из этого, с изделием нужно связать данные, которые:
относятся к проектированию;
относятся к изготовлению;
важны для хранения и учета.
Эти данные могут быть инкапсулированы в отдельных классах:
Проектировщик — хранит информацию о том, кто проектировал. Изготовитель — хранит информацию об изготовителе и способе изготовления. Регистратор — хранит информацию, важную для регистрации и учета.
Таким образом, отдельное Изделие сожно представить в виде набора из трех ссылок на три объекта:
Проектировщик.
Изготовитель.
Регистратор.
На C++ это можно представить так:
class CDesigner;
class CProducer;
class CRegistrar;
class CProduct
{
CDesigner * m_pDesigner;
CProducer * m_pProducer;
CRegistrar * m_pRegistrar;
};
Конкретные дизайнеры и производители могут быть выведены из базовых классов:
class CDesigner;
class CSelfDesigner : public CDesigner;
class COtherDesigner : public CDesigner;
class CProducer;
class CSelfProducer : public CProducer;
class COtherProducer : public COtherProducer;
Если классы COtherDesigner и CSelfProducer не содержат никаких данных, объекты этих классов могут быть созданы в одном экземпляре, и во всех изделиях, где это надо, должны быть ссылки на эти единственные экземпляры (здесь я применяю паттерн, который описан у Фаулера, как Special Case).
Здравствуйте, Kostyan2204, Вы писали:
K>Как это реализовать?
Ну реализовать-то это не сложно. Но, если я правильно понимаю, то вопрос в том — как это реализовать красиво с точки зрения ООП?
Когда ты говоришь, что в одном случае у класса должны быть поля, а в другом нет, то это уже отступление от канонов. Дело не в том, какие поля/свойства должны быть, а в том, каким должно быть поведение.
Т.е. — для каких участков программы важно наличие или отсутствие поля Price? Для сохранения и загрузки? Значит в некоем базовом классе Producer должны быть абстрактные методы Save и Load. А в двух наследниках SelfProducer и OtherProducer эти методы должны быть реализованы с учетом наличия или отсутствия этого поля.
Нужно по-разному отображать данные в отчете? Значит в классе Producer нужен абстрактный метод GetReportData. И т.п.
При любом другом подходе тебе так или иначе придется писать код типа
if (row.Purchased) return row.Price else return 0;
а тогда какая, собственно, разница, как все это программировать? Тогда проще всего сразу сделать один класс со всеми нужными свойствами и не париться с иерархиями, меньше проблем будет. Главное, получать доступ к данным только через специальные методы, проверяющие поля-флаги.
Обратите внимание на то, к чему тут призывают автора — завести с полдюжины дополнителных интерфейсов.
Вопрос — зачем? Чтобы вместо кода
if (!obj.IsSelfMade)
return obj.Price;
Писать код
if (!obj.Production.IsSelfMade)
return ((SelfMadeProduct)obj.Production).Price;
Ну и кому от этого легче? Тому кто пишет исходные классы? Нет, объем его работы увеличился. Тому, кто их использует? Боже, нет, его жизнь только усложнилась. Может, такой код проще поддерживать? Тоже нет. Так в чем выгода? В объектной ориентированности? Так это не ООП, это обезьянничество на тему ООП, не более того.
ООП это станет только тогда, когда для того, кто использует исходный класс, вообще не имеет значения — есть там поле Price или нет. Этого частично можно добиться спрятав внутри SelfMadeProduct некое значение поля Price по-умолчанию, но это:
1. Только полумера
2. Это проще и быстрее сделать в самом исходном классе, чем писать три дополнительных.
Построение иерархии становится оправданным только тогда, когда вы используете полиморфность на полную катушку — наделяя разных наследников разным поведением.
Здравствуйте, mrozov, Вы писали:
M>Забавные люди, ей-богу...
M>Обратите внимание на то, к чему тут призывают автора — завести с полдюжины дополнителных интерфейсов. M>Вопрос — зачем? M>..... M>Ну и кому от этого легче?
А где написано что аффтара к таким извращениям подталкивают? По моему в обеих примерах есть ключевой глюк: в обоих if-ах опущена ветка else. Она необходима в любом случае, поэтому если туда написать сколько-нибудь осмысленную обрабоку, то станет очевидным рефакторинг:
return obj.Production.Price;
с выносом логики расчета цены в соотвествующие классы. В этом случае мы используем M>полиморфность на полную катушку — наделяя разных наследников разным поведением.
Здравствуйте, SP_, Вы писали:
SP_>А где написано что аффтара к таким извращениям подталкивают?
а ссылку на изделие реализовать как ссылку на абстрактный класс, а если нужно вызывать специфические функции приводить его к одному из наследников.
А вот обратного — ни разу.
SP_>По моему в обеих примерах есть ключевой глюк: в обоих if-ах опущена ветка else
Что в нем ключевого? Это просто возможный пример. Могут быть и другие.
SP_>с выносом логики расчета цены в соотвествующие классы. В этом случае мы используем M>>полиморфность на полную катушку — наделяя разных наследников разным поведением. SP_>
Неа, вы используете пушку для стрельбы по воробьям.
Этот код:
public double Price
{
get
{
if (_isSelfMade)
return SELF_PRICE;
else
return _price;
}
}
— короче
— удобнее для понимания
— быстрее, в конце концов
Вариант с иерархией имеет смысл городить только тогда, когда меняется что-то большее, чем одно поле в зависимости от одного флага
И вот именно этот момент и важно доносить до людей — что ООП, это нечто большее, чем замена всех условных выражений наследованием.
Здравствуйте, mrozov, Вы писали:
M>Вариант с иерархией имеет смысл городить только тогда, когда меняется что-то большее, чем одно поле в зависимости от одного флага M>И вот именно этот момент и важно доносить до людей — что ООП, это нечто большее, чем замена всех условных выражений наследованием.
А меняется больше чем одно поле — кроме цены есть еще и закупщик. Да и описание в стартовом топике представляется мне максимально упрощенным с целью акцентировать проблему, а не детали бизнес-логики. Поэтому я запостил расширяемое решение.
Здравствуйте, mrozov, Вы писали:
M> Но, если я правильно понимаю, то вопрос в том — как это реализовать красиво с точки зрения ООП?
Ну давай, посмотрим, что в твоей версии не красиво, сточки зрения ООП...
M>Т.е. — для каких участков программы важно наличие или отсутствие поля Price? Для сохранения и загрузки?
Про сохранение и загрузку у автора топика ничего не было, однако что ты, что Кирилл вцепились в это сохранеие, ну да ладно..
M>Значит в некоем базовом классе Producer должны быть абстрактные методы Save и Load.
Наличие в базовом классе методов Save и Load — означает, что конкретная реализация класса должна знать о конкретном хранилище, куда придется сохранять цену. То есть, возникает совершенно ненужная связь, между классом продукта и хранилищем. Не нужная, потому что хранилище может быть самым разным для одного и того же объекта, в зависимости от ситуации — БД, XML, обычный файл и вообще все что угодно. А вдруг нам этот объект на удаленного клиента передать надо, будем и на клиенте такое же хранилище поддерживать и все эти потроха с собой таскать?
Теоретически, этой зависимости можно избежать, но зачем придумывать обходные маневры в виде красивых паттернов, когда можно просто не загонять себя в такую ситуацию, где эти маневры нужны?
Отсюда вывод, методов Save и Load ни в базовом классе, ни в классах конкертных продуктов быть не должно, в обычной коллекции методы Add и Remove разьве в объекте находятся, который сам себя в коллекцию помещает?
M>А в двух наследниках SelfProducer и OtherProducer эти методы должны быть реализованы с учетом наличия или отсутствия этого поля.
Полиморфизма можно добиться не только через наследование.
M>Нужно по-разному отображать данные в отчете? Значит в классе Producer нужен абстрактный метод GetReportData. И т.п.
То есть, мы еще в класс продукта и особенности его отображения запихнем? Тоже отличная идея. Что будем делать, если надо поразному данные о продуктах предоставлять, скажем, в виде таблицы и графика? А если разным пользователям, по разному его показывать надо, еще и поддержку прав там же реализуем?
M>При любом другом подходе тебе так или иначе придется писать
Не придется.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, mrozov, Вы писали:
M>> Но, если я правильно понимаю, то вопрос в том — как это реализовать красиво с точки зрения ООП? IB>Ну давай, посмотрим, что в твоей версии не красиво, сточки зрения ООП...
M>>Т.е. — для каких участков программы важно наличие или отсутствие поля Price? Для сохранения и загрузки? IB>Про сохранение и загрузку у автора топика ничего не было, однако что ты, что Кирилл вцепились в это сохранеие, ну да ладно..
Это называется "пример". Ты это слово не заметил или не понял?
M>>Значит в некоем базовом классе Producer должны быть абстрактные методы Save и Load. IB>Наличие в базовом классе методов Save и Load — означает, что конкретная реализация класса должна знать о конкретном хранилище, куда придется сохранять цену.
Нет, не означает.
IB>То есть, возникает совершенно ненужная связь, между классом продукта и хранилищем. Не нужная, потому что хранилище может быть самым разным для одного и того же объекта, в зависимости от ситуации — БД, XML, обычный файл и вообще все что угодно.
Нет, не значит. IB>А вдруг нам этот объект на удаленного клиента передать надо, будем и на клиенте такое же хранилище поддерживать и все эти потроха с собой таскать?
Есть понятие "сериализация". А еще есть паттерн "стратегия".
IB>Теоретически, этой зависимости можно избежать, но зачем придумывать обходные маневры в виде красивых паттернов, когда можно просто не загонять себя в такую ситуацию, где эти маневры нужны? IB>Отсюда вывод, методов Save и Load ни в базовом классе, ни в классах конкертных продуктов быть не должно,
Неправильный вывод. Когда как, зависит от многих прочих равных.
IB>в обычной коллекции методы Add и Remove разьве в объекте находятся, который сам себя в коллекцию помещает?
Иногда (если при добавлении объекта в коллекцию нужно выполнть доплнительные шаги) в объекте появляются специальные методы, парные им.
M>>А в двух наследниках SelfProducer и OtherProducer эти методы должны быть реализованы с учетом наличия или отсутствия этого поля. IB>Полиморфизма можно добиться не только через наследование.
Я именно об этом и написал, ты не заметил или не понял?
M>>Нужно по-разному отображать данные в отчете? Значит в классе Producer нужен абстрактный метод GetReportData. И т.п. IB>То есть, мы еще в класс продукта и особенности его отображения запихнем? Тоже отличная идея. Что будем делать, если надо поразному данные о продуктах предоставлять, скажем, в виде таблицы и графика? А если разным пользователям, по разному его показывать надо, еще и поддержку прав там же реализуем?
То мы введем стратегию отображения в том или ином виде. И привяжем ее к этому конкретному потомку. Так или иначе.
M>>При любом другом подходе тебе так или иначе придется писать IB>Не придется.
Придется. Без вариантов.
Здравствуйте, SP_, Вы писали:
SP_>Здравствуйте, mrozov, Вы писали:
M>>Вариант с иерархией имеет смысл городить только тогда, когда меняется что-то большее, чем одно поле в зависимости от одного флага M>>И вот именно этот момент и важно доносить до людей — что ООП, это нечто большее, чем замена всех условных выражений наследованием. SP_>А меняется больше чем одно поле — кроме цены есть еще и закупщик. Да и описание в стартовом топике представляется мне максимально упрощенным с целью акцентировать проблему, а не детали бизнес-логики. Поэтому я запостил расширяемое решение.
Ты не запостил никакого решения. Ты всего-навсего описал названия классов в иерархии. Разницу чувствуешь?
Здравствуйте, SP_, Вы писали:
SP_>Здравствуйте, mrozov, Вы писали:
M>>Ты не запостил никакого решения. Ты всего-навсего описал названия классов в иерархии. Разницу чувствуешь?
SP_>А что есть какие то проблемы с реализацией этих классов?
Разумеется.
SP_> судя по оценкам моего поста с "названиями классов" топикстартеру все ясно
Судя по оценке у него не возникло вопросов. Это, сам понимаешь, не одно и то же.
Сформулирую иначе — человек, который может правильно воспринять столь лаконичный совет, в таком совете попросту не нуждается. Надеюсь, спорить не станешь?
Здравствуйте, mrozov, Вы писали:
M>Это называется "пример". Ты это слово не заметил или не понял?
Где там это слово? =)
M>Нет, не означает.
А какой ценой это "не означает"? Можешь привести решение, которое позволит при наличии в самом "Продукте" методов Save и Load избавить "Продукт" от знаний о конкретном хранилище? Учти так же, что Load, как правило, производится не конкретного объекта, а коллекции объектов по самым разным предикатам.
IB>>То есть, возникает совершенно ненужная связь, между классом продукта и хранилищем. Не нужная, потому что хранилище может быть самым разным для одного и того же объекта, в зависимости от ситуации — БД, XML, обычный файл и вообще все что угодно. M>Нет, не значит.
Хоть сам-то понял на что ответил? =) Ты утверждаешь, что у автора топика гарантировано будет одно хранилище с фиксированной структурой, которое не поменяется в течении жизни приложения... Смело.
M>Есть понятие "сериализация".
Понятие "сериализация" позволит тебе передать объект на клиента. Но твой объект оказался связан с внешним миром (хранилищем), поэтому для адекватной работы этого объекта на клиенте необходимо воссоздать окружение, с которым объект работает. Это одно из проявлений проблем с излишней связностью. Более того, даже если забыть про распределенные системы, нам банально надо передавать этот объект между слоями приложения и, например, в UI методам Load и Save делать абсолютно нечего. Как будем ограничивать? Будем надеяться на аккуратность разработчика или придумывать DTO для передачи данных между слоями?
M>А еще есть паттерн "стратегия".
Есть много замечательных паттернов, но с двух попыток боюсь, ты не угадал.. Наверное самый логичный выход из такой ситуации, воспользоваться паттерном DTO, но зачем бороться с проблемами с помощю паттернов, когда можно их просто не создавать? То есть, убрать из объекта зависимость от хранилища, выкинув оттуда методы Save и Load и поместив их в соответствующий сервис?
M>Неправильный вывод. Когда как, зависит от многих прочих равных.
Правильный, при прочих равных.
M>Иногда (если при добавлении объекта в коллекцию нужно выполнть доплнительные шаги) в объекте появляются специальные методы, парные им.
И часто такое бывает? Можешь придумать пример, чтобы возникла такая необходимость в данной задаче?
M>Я именно об этом и написал, ты не заметил или не понял?
Нет, ты писал как раз про полиморфизм через наследование, либо не смог свою мысль правильно донести...
M>То мы введем стратегию отображения в том или ином виде.
Стратегия, как я посмотрю, твой любимый паттерн.. ) Так кто у нас будет формировать данные для отображения, стратегия или сам класс? И где у нас таки должен находиться метод формирования ReportData?
M>И привяжем ее к этому конкретному потомку. Так или иначе.
Так "так" или "иначе", и в каком виде?
M>Придется. Без вариантов.
=) То что ты вариантов не знаешь, не значит что их нет..
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, mrozov, Вы писали:
M>>Нет, не означает. IB>А какой ценой это "не означает"? Можешь привести решение, которое позволит при наличии в самом "Продукте" методов Save и Load избавить "Продукт" от знаний о конкретном хранилище?
Я тебе приведу два:
— сериализация — сохранение в Stream
— метод save/load является фабрикой для объектов, которые как раз и совмещают знание внутренности данного с конкретным хранилищем.
Фаулера почитай, в конце концов.
M>>Нет, не значит. IB>Хоть сам-то понял на что ответил? =) Ты утверждаешь, что у автора топика гарантировано будет одно хранилище с фиксированной структурой, которое не поменяется в течении жизни приложения... Смело.
Я ничего такого не утверждаю, это ты у нас мастер неудачного чтения чужих мыслей.
Я уже не говорю о том, что первая часть твоего утверждения не имеет отношения ко второй.
M>>Есть понятие "сериализация". IB>Понятие "сериализация" позволит тебе передать объект на клиента.
Два балла. Понятие "сериализация" позволяет мне сохранить данные в поток и восстановить из него. Это идеальный патерн для всех ситуаций, когда внутренее содержимое данных не имеет значения для кода извне.
M>>А еще есть паттерн "стратегия". IB>Есть много замечательных паттернов, но с двух попыток боюсь, ты не угадал..
Бояться не надо, надо знать.
Фабричный метод + стратегия.
IB>Наверное самый логичный выход из такой ситуации, воспользоваться паттерном DTO, но зачем бороться с проблемами с помощю паттернов, когда можно их просто не создавать? То есть, убрать из объекта зависимость от хранилища, выкинув оттуда методы Save и Load и поместив их в соответствующий сервис?
Потому что для этого с внутренним содержимым должен уметь работать этот сервис.
Что возможно и даже оптимально (отражение + кодогенерация), но к ООП уже никакого отношения не имеет.
M>>Неправильный вывод. Когда как, зависит от многих прочих равных. IB>Правильный, при прочих равных.
Глупый, если уж говорить точнее.
M>>Иногда (если при добавлении объекта в коллекцию нужно выполнть доплнительные шаги) в объекте появляются специальные методы, парные им. IB>И часто такое бывает? Можешь придумать пример, чтобы возникла такая необходимость в данной задаче?
А при чем тут часто или нечасто? Такое бывает редко, благодаря универсальности операции добавления указателя в список. Но мне доводилось делать.
M>>Я именно об этом и написал, ты не заметил или не понял? IB>Нет, ты писал как раз про полиморфизм через наследование, либо не смог свою мысль правильно донести...
Ты не смог это понять, что не то же самое. Я в конце написал, что для простых случаев проще всего вопользоваться условным выражением.
M>>То мы введем стратегию отображения в том или ином виде. IB>Стратегия, как я посмотрю, твой любимый паттерн.. ) Так кто у нас будет формировать данные для отображения, стратегия или сам класс?
По обстоятельствам. Если поддержка разных вариантов сохранения не нужна (а она как правило не нужна), то в классе. IB>И где у нас таки должен находиться метод формирования ReportData?
По обстоятельствам. Чаще всего в хранимой процедуре Несколько реже — в классе, разумеется. На выходе она будет выдавать что-то типа xml-я, воспринимаемого компонентой формирования отчета.
M>>И привяжем ее к этому конкретному потомку. Так или иначе. IB>Так "так" или "иначе", и в каком виде?
По обстоятельствам. Хоть через Spring, это детали.
M>>Придется. Без вариантов. IB>=) То что ты вариантов не знаешь, не значит что их нет..
Правильных ООП-вариантов нет. Другие существуют, но они еще сложнее.
)
Мы уже победили, просто это еще не так заметно...
