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

M>Я тебе приведу два:
опять с двух попыток не угадал..

M> — сериализация — сохранение в Stream
Это означает, что Save и Load знают о конкретном Stream aka Хранилище...

M> — метод save/load является фабрикой для объектов, которые как раз и совмещают знание внутренности данного с конкретным хранилищем.
Угу, то есть, поскольку Save и Load сидят в объекте, то они знают о конкретном хранилище, мло того, здесь еще и нарушается принцип SRP — методы сохранения являются еще и фабриками.

M>Фаулера почитай, в конце концов.
То, что ты паттерны знаешь — это понятно, осталось научиться их применять...

M>Я ничего такого не утверждаю,
Ну перечитай, как еще можно истолковать твое утверждение?

M> это ты у нас мастер неудачного чтения чужих мыслей.
Я и не претендую, если не получается правильно их излагать — приходится догадываться...

M>Два балла. Понятие "сериализация" позволяет мне сохранить данные в поток и восстановить из него.
То есть, не поможет передать на клиента?

M>Это идеальный патерн для всех ситуаций, когда внутренее содержимое данных не имеет значения для кода извне.
И причем тут это? Тебе еще раз задачу повторить? Может быть непонятно? Надо организовать передачу "продукта" на клинтское приложение, как ты будешь это делать?
И ты так и не ответил на вопрос, как будет происходить передача объекта между слоями.

M>Бояться не надо, надо знать.
Знаю, не угадал.

M>Фабричный метод + стратегия.
Где у тебя находится фабричный метод? Стратегия чего?

M>Потому что для этого с внутренним содержимым должен уметь работать этот сервис.
Какое у данного объекта внутренне содержимое?

M>Что возможно и даже оптимально (отражение + кодогенерация), но к ООП уже никакого отношения не имеет.
Никакой кодогенерации и рефлекшена, сплошной ООП.

M>Глупый, если уж говорить точнее.
Не хами. Когда аргументы заканчиваются, можно просто промолчать.

M>А при чем тут часто или нечасто?
То есть не можешь придумать пример, чтобы возникла такая необходимость в данной задаче?
Зачем тогда вкрячивать Save и Load в класс, ради какой цели?

M>Я в конце написал, что для простых случаев проще всего вопользоваться условным выражением.
Условное выражение — это не полиморфизм.

M>По обстоятельствам. Если поддержка разных вариантов сохранения не нужна (а она как правило не нужна), то в классе.
А при сохранении будем разбираться, вот это хранить, а вто это в сад? Удачное решение.

M> Несколько реже — в классе, разумеется.
Разумеется нет, никогда в классе.

M>По обстоятельствам.
Ну хоть один прием?

M>Правильных ООП-вариантов нет.
Ты же знаешь паттерны — неужели ни один в голову не приходит?

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

Любопытно, нахрена ты сразу начал хамить, чем я тебя обидел? Превосходством в интеллекте?

Мне неинтересно с тобой спорить в таком духе, понимаешь? Я привел два классических примера из учебников по ООД. Сохранение/загрузка и отображение в отчете. Фаулер и .. уже не помню, Кериевски, что ли? Ты эти примеры даже не узнал и с ходу пошел плеваться минусами и оскорблениями.

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

Желаю удачи тебе и твоим работодателям.

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

M>Этот код:
M>

M>public double Price
M>{
M> get
M> {
M>  if (_isSelfMade)
M>    return SELF_PRICE;
M>  else
M>    return _price;
M> }
M>}
M>

M> — короче
Да.
M> — удобнее для понимания
Нет. И еще раз нет.
M> — быстрее, в конце концов
Нет.

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

Автор: SP_
Дата: 10.07.07

мы имеем классический пример агрегации. Фактически по типизации мы можем сказать, что данный объект имеет цену, или нет скрывая реализацию за интерфейсом. Мы можем собрать коллекцию IPurchased и обрабатывать ее единобразным образом. Мы можем забыть об основном объекте и просто раздавать IPurchased тем методам которым интересна только цена, а не состояние объекта. В твоем случае, мы получаем полное безразличие компилятора и проблему в том, что если возвращается цена, то это совсем не значит что мы ее купили, а значит только то, что нужно еще дополнительно ее проверить. И это не совсем есть гут.

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

M>Любопытно, нахрена ты сразу начал хамить, чем я тебя обидел?
Я ?! Ты ничего не напутал? Перечитай что ли...

M>Мне неинтересно с тобой спорить в таком духе, понимаешь?
То есть, аргументов по делу нет? Я вообщем-то с самого начала это подозревал.

M>Я привел два классических примера из учебников по ООД.
А своих мозгов нету? Если это примеры из учебников, то выкинини эти учебники (ну или перечитай их правильно), так как я тебе привел классические косяки такого подхода. Ты случайно не книжки по антипаттернам читал, не разобравшись?

M> Сохранение/загрузка и отображение в отчете. Фаулер и .. уже не помню, Кериевски, что ли?
Ты прежде чем примеры приводить, разобрался бы к чему они... Фаулера поначалу не читай, его потом надо, начни с Меерса, Макконела и Саттера.

M>Ты эти примеры даже не узнал
Ну почему, характерные антипаттерны сложно не опознать.

M>То, о чем я говорю, применяется в индустрии уже десятилетиями.
Ты что-то путашеь. От этого десятилетиями предостерегают.

M>Та же сериализация, позволяющая сохранять данные
"Сериализация" ничего не хранит, это процесс упорядочивания и не более того. Как ты это упорядочивание собираешься использовать?
Такое впечатление, что ты начитался красивых слов про умные паттерны, но не очень представляешь где их применять...

M> в любом контейнере, поддерживающим интерфейс Stream.
Можешь огласить публичный контракт "интерфейса Stream"? Может быть он у Фаулера описан или еще у кого, главу не подскажешь?

M> Методы типа Dump и прочее, прочее, прочее..
Какой Dump, что прочее? Свои мысли есть или все на дядьку Мартина ссылаться будешь? Я тебе назадавал кучу вопросов, можешь на них внятно ответить? Там ничего сложного нет.

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

Продемонстрировал массу понтов и мало знаний, а на заданные вопросы так по делу ничего ответить и не смог.

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

M>> Сохранение/загрузка и отображение в отчете. Фаулер и .. уже не помню, Кериевски, что ли?
IB>Ты прежде чем примеры приводить, разобрался бы к чему они... Фаулера поначалу не читай, его потом надо, начни с Меерса, Макконела и Саттера.

Меерса обязательно! Он много про такие косяки пишет.

M>> — сериализация — сохранение в Stream
IB>Это означает, что Save и Load знают о конкретном Stream aka Хранилище...

не угадал. Stream — это интерфейс к хранилищам данных, предоставляющий для сериализаторов операции побайтового чтения/записи

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

BZ>не угадал.
А я и не угадывал.

BZ>Stream — это интерфейс к хранилищам данных,
К весьма конкретным хранилищам данных, весьма конкретный интерфейс. Об чем собственно и речь.
Ограничивать себя в данной задаче стримом — это форменный мазохизм какой-то. Правильный ответ на данный вопрос — IoC, но и это не поможет убежать от всех тщательно разложенных граблей...

BZ>предоставляющий для сериализаторов операции побайтового чтения/записи
Файн, а если мне нужно не побайтовое? А на самом деле такое и нужно, я не зря про запросы с предикатами писал.

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

SP_>Здравствуйте, Kostyan2204, Вы писали:
K>>Как это реализовать?
SP_>Один из вариантов

А какие премущества/недостатки у такого решения:

class IProduction
{

};

class IDesign
{
...
}


class Izdelie : public IDesign, public IProduction 
{
}

или такого:

template<typename Poduction, typename Design>
class Izdelie : public Production, public Design
{
...
}

Ну оба варианта позволяют проще обращаться к нужным функциям.

1й вариант, позволяет всю реализацию совместить в одном месте, если иерархия неглубокая. Это удобнее чем рыться в разных файлах. На C# вроде так можно сделать.

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

Из недостатков — наследование более сильная связь, но ИМХО так будет элегантнее.

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

DC>А какие премущества/недостатки у такого решения:

Ну хотя бы это требование для начала:

Изделия могут менять признак с ПОКУПНОЕ на СОБСТВЕННОЕ ИЗГОТОВЛЕНИЕ (и наоборот)"

.

BZ>>Stream — это интерфейс к хранилищам данных,
IB>К весьма конкретным хранилищам данных, весьма конкретный интерфейс. Об чем собственно и речь.
IB>Ограничивать себя в данной задаче стримом — это форменный мазохизм какой-то. Правильный ответ на данный вопрос — IoC, но и это не поможет убежать от всех тщательно разложенных граблей...

BZ>>предоставляющий для сериализаторов операции побайтового чтения/записи
IB>Файн, а если мне нужно не побайтовое?

а если нужен интерфейс Show? или Sort? какое-то толчение воды в ступе

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

BZ>а если нужен интерфейс Show? или Sort?
Во-первых, какое отношение имеет Show к хранилищу? А во-вторых, я довольно четко описал характерные требования к типичному механизму хранения, что-то непонятно? Так я могу растолковать...

BZ> какое-то толчение воды в ступе
Я задал совершенно конкретные вопросы, даже ответ подсказал, что не устраивает?

Здравствуйте, 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>Как это реализовать?

создайте класс который умеет регистрить другой класс.
типа

static void register(name_class)
static void unregister(name_class)
static find(name_class)

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

Здравствуйте, 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>Как это реализовать?

    public class AbstractIzdelie
    {
        long _id;
        string _fullName;
        decimal _mass;
        InternalArhitect _internalArhitect;
        AlienDevelop _alienDeveloper;
        public long ID
        {
            get { return _id; }
        }
        public string FullName
        {
            get { return _fullName; }
        }
        public decimal Mass
        {
            get
            {
                return _mass;
            }
        }
        public decimal Price 
        {
            get { return _alienDeveloper.Price; }
        }
        public string Number
        { 
            get { return _internalArhitect.Number; }
        }
        public string Fio 
        {
            get { return _internalArhitect.Fio; }
        }
        public string Byer
        {
            get { return _alienDeveloper.Buyer; }
        }
    }
    struct InternalArhitect
    {
        public string Number;
        public string Fio;
    }
    struct AlienDevelop
    {
        public decimal Price;
        public string Buyer;
    }

Ещё добавить SetAsInternal — обнуляем структуру и SetAsAlien(AlienDevelop alienDeveloper)