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

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


C>>>Ну не может товар знать на складе он, или уже как списанка на помойке лежит — ибо ему это не нужно.
V>>Откуда это утверждение?

C>Потому что "на складе", "не на складе" это не свойство объекта "товар".
C>Здесь типичная композиция — HasIs.
C>В данном случае это как раз свойство объекта "склад".
C>Т.е. это "склад" владеет "товаром", а не свойство "товара" — "на складе" или "нет".

В ООП объекты моделируются как это удобно: угол, под которым мы смотрим на совокупность данных, которыми оперирует программа, может быть любым. Условия задачи определяют, что какие данные будут частью состояния объекта.

Более того, некоторые данные будут представляться в разных объектах одновременно, если это позволяет создавать компактные и адекватные объекты вместо больших и неуклюжих "универсальных" объектов, основная задача которых соответствовать предубеждениям программиста "о том как оно всё должно быть", а не решать задачу.

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

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

V>>Я уже написал, что поведение и состояние в ООП должны быть вместе.
S>Что именно значит "вместе"? И откуда это следует?

Гради Буч давно написал классический труд, там всё расписано: https://www.ozon.ru/context/detail/id/3905587/

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

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

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

V>>>Я уже написал, что поведение и состояние в ООП должны быть вместе.
S>>Что именно значит "вместе"? И откуда это следует?

V>Гради Буч давно написал классический труд, там всё расписано: https://www.ozon.ru/context/detail/id/3905587/
"Вместе" не значит "все впихнуть в одно".

То что поведение завязано на состояние, это и так понятно. Иначе нет никакого поведения просто — потому что оно (поведение) постоянно и ни от чего не зависит… Но увязывать состояние и поведение в коде — это точно не значит сложить все в один интерфейс\объект.

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

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

V>>>Я уже написал, что поведение и состояние в ООП должны быть вместе.
S>>Что именно значит "вместе"? И откуда это следует?

V>Гради Буч давно написал классический труд, там всё расписано: https://www.ozon.ru/context/detail/id/3905587/

Почему за пояснением своего тезиса вы отсылаете меня к Бучу? Я точно не буду его читать, что бы выяснить, что вы имели в виду.

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

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

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

V>>>>Я уже написал, что поведение и состояние в ООП должны быть вместе.
S>>>Что именно значит "вместе"? И откуда это следует?

V>>Гради Буч давно написал классический труд, там всё расписано: https://www.ozon.ru/context/detail/id/3905587/

S>Почему за пояснением своего тезиса вы отсылаете меня к Бучу? Я точно не буду его читать, что бы выяснить, что вы имели в виду.

Потому что нужна целая книга, чтобы описать ООП. И читать её надо обязательно.

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

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

S>>Почему за пояснением своего тезиса вы отсылаете меня к Бучу? Я точно не буду его читать, что бы выяснить, что вы имели в виду.

V>Потому что нужна целая книга, чтобы описать ООП. И читать её надо обязательно.
Что бы потом стесняться аргументации своих тезисов?

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

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

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

S>>>Почему за пояснением своего тезиса вы отсылаете меня к Бучу? Я точно не буду его читать, что бы выяснить, что вы имели в виду.

V>>Потому что нужна целая книга, чтобы описать ООП. И читать её надо обязательно.
S>Что бы потом стесняться аргументации своих тезисов?

Делать мне больше нечего, чем в очередной раз спорить о том как моделировать предметную область в ООП. Поищите мои сообщения в этом форуме, споры со сторонниками анемичных моделей и примитивного процедурного программирования я не поддерживаю — что мне с того, что люди регрессируют в процедурное программирование, когда надо думать и проектировать модели? Плохой программист создаёт два новых рабочих места в год.

Выяснить, какую роль играют поведение, состояние и идентичность объектов в ООП, не составляет никакого труда.

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

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

V>>>Потому что нужна целая книга, чтобы описать ООП. И читать её надо обязательно.
S>>Что бы потом стесняться аргументации своих тезисов?

V>Делать мне больше нечего, чем в очередной раз спорить о том как моделировать предметную область в ООП. Поищите мои сообщения в этом форуме, споры со сторонниками анемичных моделей и примитивного процедурного программирования я не поддерживаю — что мне с того, что люди регрессируют в процедурное программирование, когда надо думать и проектировать модели? Плохой программист создаёт два новых рабочих места в год.
Все, все. Пойду создавать новые рабочие места. Кому-то же надо этим заниматься.

V>Выяснить, какую роль играют поведение, состояние и идентичность объектов в ООП, не составляет никакого труда.
Я хотел выяснить немного другое. Что значит что поведение и состояние в ООП должны быть вместе и почему логику продажи в труООП надо совать в товар.

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

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

S>>Если нужно продать 3 товара по цене двух, то у какого из них вызывать метод Sell?

V>Один объект, один вызов. Разумно предположить, что этот объект представляет сразу сам товар, и его количество, и все дополнительные правила продажи.

type Product = {
    Price : decimal
}

type OrderLine = {
    Product : Product
    Count : int
    Discount : decimal
}

type Order = {
    Client : string
    Lines : list[OrderLine]
}

type ISaleService = {
    CreateOrder : (string, list[OrderLine]) -> Order
    AddLineToOrder : ...
    Sell : ...
}

Короче, думаю, надо отталкиваться от реальной схемы.
Например, проданный товар нельзя продать(разные сущности).
Схема продажи(алгоритм расчета стоимости может быть выражен через аргумент в виде делегата-функции,
принимающей наименование товара/код, количество, способ оплаты, скидку и т.п.

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


C>Это вопрос чисто теоретический или практический?

Практический!

C>Если практический, то не используем никаких нафиг там стратегий, а пишем тупой код с if'ами для разных типов товаров. После того, как будут написаны (как минимум) продажи для 3 типов товаров, то смотрим, что можно объединить и абстрагировать.

Да вот нечто такое уже есть и хочется от if'ов избавиться. Но я ума не приложу как это сделать иначе, чем ссылку на логику продажи пихнуть в товар. То есть при создании товара создавать нужного seller'a и хранить его в товаре. И когда надо — применять. Если этого не делать, то как выбирать нужного seller'a? Допустим возьмём предложенный подход с третьей сущностью — сделка. В сделке будет метод Sell. Получается он должен принимать товар и алгоритм продажи. Так вот мне непонятно, откуда возьмётся нужный алгоритм продажи?

class Deal
{
    void MakeSellDeal(baseClass a, ISeller seller)
    {
        seller.Sell(a);
    }
}

Ведь неизвестно какой тип товара... Только если товар при создании создавал бы в себе нужный seller. А иначе придётся проверять тип товара if'ами?
Но в топике некоторые несогласны с таким подходом, утверждая, что товар сам себя не продаёт. Я согласен в принципе с этим, но как сделать по-другому, без if'ов и без того, чтобы seller был свойством товара я не понимаю.

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

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

C>>Я понимаю, что вопрос тот ещё. Но может всё-таки я где-то блуждаю не там?
C>>Что можно сказать про "магазин"? Типов товаров будет немного, всего около 7-8. Ещё магазин должен будет каждый товар уметь принимать на склад, принимать бракованый товар назад, отсылать товар в ремонт и т.д.
C>>Даже этот список дейтсвий помножить на 7 получится ~30 методов в IShop для первого примера. А для второго примера получится, что не магазин управляет товаром, а товар управляет сам собой ...
C>>Лично мне больше нравится второй пример, если б не то обстоятельство, что товар сам себя "обслуживает". Или это нормально? Посоветуйте, пожалуйста, что-нибудь! Может другой паттерн или где-то я ошибся в реализации?
C>>использую c#
C>>Спасибо.

S>А почему не:

S>

S>class Shop : IShop
S>{
S>    public void Sell(ISeller seller)
S>    {

S>    }
S>}
S>

S>Товары продавать должен все-таки магазин, но у каждого товара может быть своя специфика.

Как тогда выбрать нужного seller? Перед вызовом Sell проверять if'ами тип товара?
Извините не совсем понял идею.

Товары продает магазин.
Модель имхо такая

1) создаются объекты покупателей (с некоторой частотой)

2) объекты витрины посылают покупателям сигналы с описанием объектов товаров

3) в ответ покупатели посылают сигналы с запросами на получение товаров в некоторых кол-вах к витрине

4) обмен данными витрины и покупателей

5) обмен данными витрин и склада

6) покупатель обменивается данными с объектом касса

7) покупатель уходит из магазина (объект покупатель уничтожается и все объекты товары связанные с ним )

8) Объект Супервайзер-магазина создает и уничтожает объекты витрин по признакам нет товаров, нет методов продажи и тд. удаление из вирин просрочки
перемещет товары изсклада на итины итд. Супервайзер запрашивает инфу о методах продаж у объекта маркетолог

8) описание методов продаж всех товаров содержится в объекте маркетолог, там же дефолтные методы продаж для всех товаров в том числе которых нет
на складе и витринах.

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

C>>Если практический, то не используем никаких нафиг там стратегий, а пишем тупой код с if'ами для разных типов товаров. После того, как будут написаны (как минимум) продажи для 3 типов товаров, то смотрим, что можно объединить и абстрагировать.
C>Да вот нечто такое уже есть и хочется от if'ов избавиться. Но я ума не приложу как это сделать иначе, чем ссылку на логику продажи пихнуть в товар. То есть при создании товара создавать нужного seller'a и хранить его в товаре.
Ну значит, и не надо ничего менять. Пусть остаются if'ы — в них нет ничего плохого.

Можно, конечно, попробовать создать что-то типа "<xxx>Workflow", в который запихать методы продажи. В товары добавить идентификатор типа workflow, и делать диспетчеризацию в коде продажи.

Но вообще, без конкретного кода и требований тут можно только абстрактно махать руками — пользы от этого очень мало будет.

C>Ведь неизвестно какой тип товара... Только если товар при создании создавал бы в себе нужный seller. А иначе придётся проверять тип товара if'ами?
Да, а что?

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

C>Как тогда выбрать нужного seller? Перед вызовом Sell проверять if'ами тип товара?
C>Извините не совсем понял идею.

Согласен, что непонятоно. Я имел в виду следующее: товар не должен сам себя продавать, продавать его должен магазин. Взаимодействие магазина и товара тоже должно быть простым и прямолинейным. Т.е. тут, вероятно,
должна быть третья сущность, которая взяла бы на себя всю сложность бизнес логики и связывания IShop и ISell.

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

C>По моему тут не через паттерн "стратегия" нужно делать, а через паттерн "визитер".

Вот как получилось через паттерн визитёр. Можно запустить на dotnetfiddle
Интересно узнать у кого какое мнение на этот вариант.

using System;
using System.Collections.Generic;


namespace visitor_example
{
    abstract class baseClass
    {
        public abstract string AcceptSellVisitor(ISeller visitor);
        public abstract string AcceptReclamationVisitor(IReclamation visitor);
    }

    class A : baseClass
    {
        public string Name = "A";
        public override string AcceptSellVisitor(ISeller visitor)
        {
            return visitor.Sell(this);
        }
        public override string AcceptReclamationVisitor(IReclamation visitor)
        {
            return visitor.Reclamate(this);
        }
    }

    class B : baseClass
    {
       public string Name = "B";
       public override string AcceptSellVisitor(ISeller visitor)
        {
            return visitor.Sell(this);
        }
        public override string AcceptReclamationVisitor(IReclamation visitor)
        {
            return visitor.Reclamate(this);
        }
    }

    interface ISeller
    {
        string Sell(A item);
        string Sell(B item);
    }
     interface IReclamation
    {
        string Reclamate(A item);
        string Reclamate(B item);
    }
    class SellVisitor : ISeller
    {
        public string Sell(A item)
        {
            return "Sell A "+item.Name;
        }
        public string Sell(B item)
        {
            return "Sell B "+item.Name;
        }
    }
    class ReclamationVisitor : IReclamation
    {
        public string Reclamate(A item)
        {
            return "Reclamate A "+item.Name;
        }
        public string Reclamate(B item)
        {
            return "Reclamate B "+item.Name;
        }
    }
    class Shop
    {
            public SellVisitor sell = new SellVisitor();
            public ReclamationVisitor recl = new ReclamationVisitor();
    }
    public class Program
    {
        public static void Main()
        {
            Shop shop = new Shop();
            var list = new List<baseClass> { new A(), new B(), new A(), new A(), new B() };
            foreach (var item in list)
            {
                Console.WriteLine(item.AcceptSellVisitor(shop.sell));
                Console.WriteLine(item.AcceptReclamationVisitor(shop.recl));
            }
        }
    }
}

C>Или же заводить еще один интерфейс "покупка" (ну или "продажа"), который завязан на два других интерфейса. "Магазин" и "товар". Через параметры, или ссылки.
C>Явно же напрашивается третья сущность…

Тут я не совсем понял. Типа интерфейс "покупка" имеет метод, который принимает два интерфейса "магазин" и "товар"? А как тогда он будет определять как именно продавать? if'ами определить тип товара?

Спасибо.

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

V>>Выяснить, какую роль играют поведение, состояние и идентичность объектов в ООП, не составляет никакого труда.
S>Я хотел выяснить немного другое. Что значит что поведение и состояние в ООП должны быть вместе и почему логику продажи в труООП надо совать в товар.

Гради Буч написал книгу, чтобы объяснить эти фундаментальные концепции. Читать надо, вот прямая цитата:

Объекты не существуют изолированно, а подвергаются воздействию или сами воздействуют на другие объекты.
Поведение — это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений.
Иными словами, поведение объекта — это его наблюдаемая и проверяемая извне деятельность.
Операцией называется определенное воздействие одного объекта на другой с целью вызвать соответствующую реакцию. Например, клиент может активизировать операции append и pop для того, чтобы управлять объектом-очередью (добавить или изъять элемент). Существует также операция length, которая позволяет определить размер очереди, но не может изменить это значение. В чисто объектно-ориентированном языке, таком как Smalltalk, принято говорить о передаче сообщений между объектами. В языках типа C++, в которых четче ощущается процедурное прошлое, мы говорим, что один объект вызывает функцию-член другого. В основном понятие сообщение совпадает с понятием операции над объектами, хотя механизм передачи различен. Для наших целей эти два термина могут использоваться как синонимы.
В объектно-ориентированных языках операции, выполняемые над данным объектом, называются методами и входят в определение класса объекта. В C++ они называются функциями-членами. Мы будем использовать эти термины как синонимы.
Передача сообщений — это одна часть уравнения, задающего поведение. Из нашего определения следует, что состояние объекта также влияет на его поведение. Рассмотрим торговый автомат. Мы можем сделать выбор, но поведение автомата будет зависеть от его состояния. Если мы не опустили в него достаточную сумму, скорее всего ничего не произойдет. Если же денег достаточно, автомат выдаст нам желаемое (и тем самым изменит свое состояние). Итак, поведение объекта определяется выполняемыми над ним операциями и его состоянием, причем некоторые операции имеют побочное действие: они изменяют состояние. Концепция побочного действия позволяет уточнить наше определение состояния:
Состояние объекта представляет суммарный результат его поведения.
Наиболее интересны те объекты, состояние которых не статично: их состояние изменяется и запрашивается операциями.

Почему у класса List<T> есть метод Add? Это же я добавляю элемент в список, список сам себя не заполняет!!! У меня будет простой и понятный объект ListManager, у которого и будет набор методов для работы со списком. А список это всего лишь структура данных!

Спорить на фундаментальном уровне — заниматься бесполезным ликбезом для ленивых умов.

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

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

V>>>Выяснить, какую роль играют поведение, состояние и идентичность объектов в ООП, не составляет никакого труда.
S>>Я хотел выяснить немного другое. Что значит что поведение и состояние в ООП должны быть вместе и почему логику продажи в труООП надо совать в товар.

V>Гради Буч написал книгу, чтобы объяснить эти фундаментальные концепции. Читать надо, вот прямая цитата:

V>

V>Объекты не существуют изолированно, а подвергаются воздействию или сами воздействуют на другие объекты.
V> Поведение — это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений.
V> Иными словами, поведение объекта — это его наблюдаемая и проверяемая извне деятельность.
V> Операцией называется определенное воздействие одного объекта на другой с целью вызвать соответствующую реакцию. Например, клиент может активизировать операции append и pop для того, чтобы управлять объектом-очередью (добавить или изъять элемент). Существует также операция length, которая позволяет определить размер очереди, но не может изменить это значение. В чисто объектно-ориентированном языке, таком как Smalltalk, принято говорить о передаче сообщений между объектами. В языках типа C++, в которых четче ощущается процедурное прошлое, мы говорим, что один объект вызывает функцию-член другого. В основном понятие сообщение совпадает с понятием операции над объектами, хотя механизм передачи различен. Для наших целей эти два термина могут использоваться как синонимы.
V> В объектно-ориентированных языках операции, выполняемые над данным объектом, называются методами и входят в определение класса объекта. В C++ они называются функциями-членами. Мы будем использовать эти термины как синонимы.
V> Передача сообщений — это одна часть уравнения, задающего поведение. Из нашего определения следует, что состояние объекта также влияет на его поведение. Рассмотрим торговый автомат. Мы можем сделать выбор, но поведение автомата будет зависеть от его состояния. Если мы не опустили в него достаточную сумму, скорее всего ничего не произойдет. Если же денег достаточно, автомат выдаст нам желаемое (и тем самым изменит свое состояние). Итак, поведение объекта определяется выполняемыми над ним операциями и его состоянием, причем некоторые операции имеют побочное действие: они изменяют состояние. Концепция побочного действия позволяет уточнить наше определение состояния:
V> Состояние объекта представляет суммарный результат его поведения.
V> Наиболее интересны те объекты, состояние которых не статично: их состояние изменяется и запрашивается операциями.

V>Почему у класса List<T> есть метод Add? Это же я добавляю элемент в список, список сам себя не заполняет!!! У меня будет простой и понятный объект ListManager, у которого и будет набор методов для работы со списком. А список это всего лишь структура данных!

V>Спорить на фундаментальном уровне — заниматься бесполезным ликбезом для ленивых умов.

Спорить с Бучем здесь совершенно не о чем. Он предлагает соглашение — что именно называть поведением и операциями. Но совершенно не понятно откуда из процитированного следует что метод Sell должен быть у зубочистки, как поменяется состояние товара "зубочистка" при вызове этого метода.
Более того, в примере Буча рассмотрен торговый автомат, который меняет свое состояние. Но не упомянуты состояния товаров, которыми оперирует автомат. Странно, но процитированное не предполагает труООП-шности товара, проданного автоматом. Может быть надо читать дальше?

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

S>Спорить с Бучем здесь совершенно не о чем. Он предлагает соглашение — что именно называть поведением и операциями. Но совершенно не понятно откуда из процитированного следует что метод Sell должен быть у зубочистки, как поменяется состояние товара "зубочистка" при вызове этого метода.

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

Товар Зубочистка при вызове метода Продать может как минимум уменьшить своё свойство Количество на единицу.

S>Более того, в примере Буча рассмотрен торговый автомат, который меняет свое состояние. Но не упомянуты состояния товаров, которыми оперирует автомат. Странно, но процитированное не предполагает труООП-шности товара, проданного автоматом. Может быть надо читать дальше?

Да, надо читать дальше — в книге есть примеры программ и описан процесс проектирования объектов.

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

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

S>>Спорить с Бучем здесь совершенно не о чем. Он предлагает соглашение — что именно называть поведением и операциями. Но совершенно не понятно откуда из процитированного следует что метод Sell должен быть у зубочистки, как поменяется состояние товара "зубочистка" при вызове этого метода.

V>Воздействие одного объекта (субъект) на другой (объект) называется операцией и реализуется в виде метода объекта, потому что объекты сами меняют своё состояние (инкапсуляция). Поведение реализуется в объекте, а не в субъектах, потому что именно такой подход позволяет лучше контролировать состояние объекта. Субъектов может быть множество, если объект не имеет собственного поведения, его границы размываются и мы больше не имеем отдельной сущности, а просто набор данных, изменение которых не контролируется.
Я бы вывернул все наизнанку. Операции реализуются в виде методов не потому "что объекты сами меняют свое состояние (инкапсуляция)". Первичен контракт, или поведение системы (пусть системы объектов). Как там хранится состояние, как делится между объектами — дело вообще десятое. Например, может быть ОО фасад над абсолютно открытым набором данных (допустим, JSON). Т.е. пока есть контракт, пока он выполняется, никому нет дела до того, чье состояние меняет объект. И именно это есть инкапсуляция в широком смысле, как двойственное понятие барьеру абстракции, а не приписывание состояния объектам. А если шагнуть дальше — то есть примеры контрактов без состояния, следовательно без поведения. Контролировать проще.

V>Товар Зубочистка при вызове метода Продать может как минимум уменьшить своё свойство Количество на единицу.
Не лучшая идея — держать живое Количество в товаре. Им очень тяжело управлять, имея несколько товаров в чеке и конкуренцию за доступ к этому свойству каждого товара. Сразу начинает болеть голова от персистентности этого состояния, согласованности с другими данными (журнал продаж, поставок на склад и т.п.).
Вообще говоря, не вполне очевидно, почему свойство Количество приписано к товару Зубочистка. И почему оно должно уменьшаться именно на единицу при вызове метода Продать? Продать можно и зубочистки, которые не поставили на склад и даже не изготовили. Ну а почему нет?
А если у нас в зубочистке нет счетчика, то и обращаться к нему "ПродайСебя" вроде как смысла нет.

S>>Более того, в примере Буча рассмотрен торговый автомат, который меняет свое состояние. Но не упомянуты состояния товаров, которыми оперирует автомат. Странно, но процитированное не предполагает труООП-шности товара, проданного автоматом. Может быть надо читать дальше?

V>Да, надо читать дальше — в книге есть примеры программ и описан процесс проектирования объектов.
То есть, процитированное выше — не есть обоснование наличия метода Продайся у товара? Ну так а зачем оно тогда, раз не отвечает на мой вопрос?