Re[5]: Множественное наследование, mix-in-ы, traits
От: Kluev  
Дата: 15.05.06 08:03
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>О как. Мы противопоставляем модль и документ. А что же тогда такое документ как не модель?


K>> который юзается для отрисовки и UI манипуляций. т.е. не классичесский doc — view, а doc — proxy_doc — view. Где doc — модель, proxy_doc — сцена3д, view — окно_сцены.


VD>Нда. Эту уже на концептуальном уровне выглядит страшно. Раньше все было просо "модель-представление-контроллер". Как разновидность интеграция контроллера в представление. Прокси использовался для создания переходника интерфейса. А тут прям новые концепции. Вот только один вопрос. А оно надо?


Тем не менее все САD-ы именно так и устроены. Все используют промежуточное представление (proxy-doc) для view.
В документе модели 3-д обьекты представлены в аналитическом виде, т.к. манипуляции и вычисление удобно делать с аналитикой и сплайнами, а графическая подсистема не понимает ничего кроме треугольников. Я еще не видел ни одной программы которая бы триангулировала бы поверхности на лету во время рендера. Такой дизайн с прокси документом очевиден и правилен, а вот обычный документ вид здесь ни на что не годится. А если графическая подсистема (view) работает только с промежуточным представлением, то об основной модели ничего знать она и не должна. И это правильно. Такой подход позволяет, например радикально изменить структуру модели не трогая view и proxy-doc. Пример — SolidWorks. В новых версиях из него оперативно выкинули покупное ядро parasolid от unigraphics и заюзали собственное. Но если вернутся к нашим баранам т.е. м-н, и постомтреть на этот дизайн doc-proxy-doc, то видно, что обьект в такой систему будет являтся обьектом модели (doc), и может являтся участником сцены (proxy-doc). Т.е. классическое отношение is-a которое подразумевает наследование. Иными словами м-н здесь уместно даже с академической точки зрения.

K>> Преимущества такого подхода очевидны.

VD>Кому, простите?
Очевиден понятливым, кто не врубается я не виноват.

K>> Модель — крайне ветвиста и наворочена, в то время как на сцене может отображатся фактически только три примитива точка, линия и поверхность из треугольников. Взаимодействие с юзером, а именно просмотр и выбор обьектов мышкой идет через окно сцены.


VD>Ясно. А может вы просто про контроллер забыли?

Контроллер здесь не существенен и он совмещается с классами MainFrame и Docking Windows, вернее MainFrame и докируемые окна это и есть контроллеры, заводить отдельный класс нет смысла.

K>> то это было бы крайне неэффективно т.к. пришлось бы работать с кучей разных типов, которые к тому же быстро эволюционируют в процессе разработки. Выход создание промежуточного документа, и множественное наследование используется чтобы сделать обьект участником двух документов одновременно:


VD>Ну, вот мы и пришли к странному дизайну.

Расскажи это людям которые пишут Unigraphics, SolidWorks, PRO/E и другие системы, а то мужики не знают, делают странный дизайн, извращаются.

VD>В общем, чем дальше читаю эту тему, тем больше понимаю, что проблем от МН больше чем приемуществ. А ведь еще не давно я так не думал.


Не нарвится не используй никто не настаивает. Я например в ходе практики выяснил все плюсы, минусы и подводные грабли в М-Н. Поэтому юзаю там где считаю нужным. Чужие теоретические рассуждения о М-Н, мне совершенно фиолетовы.
Re: Множественное наследование, mix-in-ы, traits
От: PhantomIvan  
Дата: 15.05.06 11:39
Оценка: 26 (1)
Здравствуйте, VladD2, Вы писали:

VD>Хотелось бы услышать кто что думает по поводу необходимости подобных вещей в языках программирования.


VD>Особо привествуются примеры в которых данные фичи дают резкое упрощение решаемой задачи.


Попробуем простейший пример из баз данных: Data Access Layer. Есть хранимые процедуры, и гейты (паттерн Gateway).

    public interface IGetGateway
    {
        DataRow GetSingle(int id);
        DataTable GetMultiple();
    }

Это для получения записи по ключу или всех записей.

    public interface IDeleteGateway
    {
        int Delete(int id);
    }

Это для удаления записи.

Теперь один из гейтов:
    public class PollGateway : GetGateway, IGetGateway, IDeleteGateway
    {
        private DeleteHelper deleteHelper;
        
        public PollGateway(SqlConnection connection) : base(connection, "cms_polls_get")
        {
            deleteHelper = new DeleteHelper(connection, "cms_polls_del");
        }
        ...
        public int Delete(int id)
        {
            return deleteHelper.Delete(id);
        }
    }


Понятно, что представляет собой GetGateway:
    public class GetGateway : Gateway, IGetGateway
    {
        private readonly string procedure;

        public GetGateway(SqlConnection connection, string getStoredProcedure) : base(connection)
        {
            procedure = getStoredProcedure;
        }

        public virtual DataRow GetSingle(int id)
        {
        ...
        }

        public virtual DataTable GetMultiple()
        {
        ...
        }
    }
}


Теперь внимание: добавляем в IDeleteGateway метод DeleteAll. Ну, вы догадались.
Кроме того, не в каждой таблице есть ключ, т.е. не каждый гейт должен реализовать IGetGateway. А некоторым гейтам запрещено удалять записи.
Конечно, хочется поддержки сабжа в языке. А там уж думать, использовать сабж или нет, а если да, то как это делать по уму.

P.S. traits-проект для C# здесь, при поддержке microsoft
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Множественное наследование, mix-in-ы, traits
От: A.Lokotkov Россия http://www.linkedin.com/pub/alexander-lokotkov/a/701/625
Дата: 16.05.06 03:36
Оценка: +1 :)
Здравствуйте, WoldemaR, Вы писали:

WR>Полиморфное разделение объектов графического редактора, которое демонстрируется в каждом учебнике по ООП — тупиковый путь. индустрия ( -какое слово то!!!) от него уже давно отказалась.


Не могли бы Вы привести ссылок на тему отказа индустрии от ПРО?
bloß it hudla
Re[5]: Множественное наследование, mix-in-ы, traits
От: WoldemaR Россия  
Дата: 16.05.06 09:43
Оценка:
Здравствуйте, A.Lokotkov, Вы писали:

AL>Не могли бы Вы привести ссылок на тему отказа индустрии от ПРО?


Вот ссылок привести немогу. Но если Вы посмотрите последние версии векторных графических редакторов: типа Corel, Flash, Xara, и т.п. то заметите что существует возможность трансформации объекта из одного "типа" в другой "тип", т.е. все объекты равнофункциональны.

А чему нас учили?
class DrawObject{};

class Line : DrawObject{};
class Circle : DrawObject{};
class Square : DrawObject{};


В современных редакторах происходит такая вещь:
Circle obj;
obj = cast<Square>(obj);


Надеюсь что понятно объяснил.
Re[6]: Множественное наследование, mix-in-ы, traits
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.05.06 20:31
Оценка:
WR>В современных редакторах происходит такая вещь:
WR>
WR>Circle obj;
WR>obj = cast<Square>(obj);
WR>


Но ведь может быть и такой код:
Figure obj = new Circle();
obj = obj.ConvertTo<Square>();
Re[7]: Множественное наследование, mix-in-ы, traits
От: WoldemaR Россия  
Дата: 17.05.06 10:53
Оценка: :)
Здравствуйте, DarkGray, Вы писали:

DG>Но ведь может быть и такой код:

DG>
DG>Figure obj = new Circle();
DG>obj = obj.ConvertTo<Square>();
DG>


Несмотря на то, что мазохизм иногда встречается в самых неожиданных формах, это не является поводом принимать извращения за правило.
Re[8]: Множественное наследование, mix-in-ы, traits
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.05.06 20:09
Оценка:
WR>Несмотря на то, что мазохизм иногда встречается в самых неожиданных формах, это не является поводом принимать извращения за правило.

А четко обосновать почему это так, сможете? или только можете общие фразы выдавать?
Re[6]: Множественное наследование, mix-in-ы, traits
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.05.06 20:53
Оценка:
Здравствуйте, eao197, Вы писали:

E>Так чем же история закончилась? И закончилась ли?


Какая? Я просто собираю солидную аргументацию чтобы использовать ее при объяснении зачем это нужно в Немерле.

Просто я думл только собрать аргументы, а получилось так, что задумался по глубже...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Множественное наследование, mix-in-ы, traits
От: WoldemaR Россия  
Дата: 18.05.06 09:44
Оценка:
Здравствуйте, DarkGray, Вы писали:


WR>>Несмотря на то, что мазохизм иногда встречается в самых неожиданных формах, это не является поводом принимать извращения за правило.


DG>А четко обосновать почему это так, сможете? или только можете общие фразы выдавать?


Понимаете в чём дело.
Если вам нравится выполнение рутинной работы, а у вашего начальства достаточно денег для использования трудоёмких текнологий, то кто я такой чтобы говорить Вам, что это плохо?
Re[9]: Множественное наследование, mix-in-ы, traits
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.05.06 20:52
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>А четко обосновать почему это так, сможете? или только можете общие фразы выдавать?


Ты не понял. Он же сказал "индустрия уже отказалась". Просто она сказала это толко ему одному. А мы просто еще не в крусе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Множественное наследование, mix-in-ы, traits
От: WoldemaR Россия  
Дата: 19.05.06 11:05
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ты не понял. Он же сказал "индустрия уже отказалась". Просто она сказала это толко ему одному. А мы просто еще не в крусе.


VladD2, да ты не комплексуй. у каждого человека есть слабые и сильные стороны.
Re[10]: Множественное наследование, mix-in-ы, traits
От: Kluev  
Дата: 19.05.06 11:33
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


DG>>А четко обосновать почему это так, сможете? или только можете общие фразы выдавать?


VD>Ты не понял. Он же сказал "индустрия уже отказалась". Просто она сказала это толко ему одному. А мы просто еще не в крусе.


Имхо, индустрия не должна быть авторитетом для разработчика.

Даже полный успех в чужой дхарме бесполезен — к своей устремляйся (Бхагават Гита)

К тому же далеко не всегда индустрия шагает верным путем. Взять к примеру ХМЛ, средняя буква означает маркап, т.е. для разметки предназначен. Но досадному недоразумению ХМЛ стали юзать везде, причем как обычно в самых извращенных формах.
Re: немного не по теме
От: mrozov  
Дата: 19.05.06 18:15
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Хотелось бы услышать кто что думает по поводу необходимости подобных вещей в языках программирования.


VD>Особо привествуются примеры в которых данные фичи дают резкое упрощение решаемой задачи.


Возможно, баян и злостный оффтопик, но все-таки.


    interface IMixin
    {}

    class SomeClass : IMixin
    {
    }

    static class Mixin
    {
        public static void DoSmth( this IMixin o )
        {
        }
    }
    
    class Pro
    {
        
        public static void Work()
        {
            SomeClass o = new SomeClass();
            
            IMixin mixin = o;
            
            mixin.DoSmth();
        }
    }

Конечно, так красиво все только для stateless mixin-ов, но я все равно шизею от дорогой редакции... Что они творят с моим любимым языком?
Re[2]: немного не по теме
От: WolfHound  
Дата: 19.05.06 19:19
Оценка:
Здравствуйте, mrozov, Вы писали:

M>Конечно, так красиво все только для stateless mixin-ов, но я все равно шизею от дорогой редакции... Что они творят с моим любимым языком?

Это сахар, а не миксины. Этим баловством нельзя реализовавать интерфейсы. Короче толку мало.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: немного не по теме
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.06 21:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

M>>Конечно, так красиво все только для stateless mixin-ов, но я все равно шизею от дорогой редакции... Что они творят с моим любимым языком?

WH>Это сахар, а не миксины. Этим баловством нельзя реализовавать интерфейсы. Короче толку мало.

Толку много, но решается другая задача.

И вот еще что... Хорошо, что они творят хотя бы это с нашим любимым языком.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: немного не по теме
От: Кирилл Осенков Украина
Дата: 05.09.07 19:27
Оценка:
M>
M>    interface IMixin ...
M>    ...
M>    static class Mixin
M>    {
M>        public static void DoSmth( this IMixin o )
M>        {
M>        }
M>    } ...
M>

M>Конечно, так красиво все только для stateless mixin-ов, но я все равно шизею от дорогой редакции... Что они творят с моим любимым языком?

Да, extension methods открывают интересные возможности:
Create Mixins with Interfaces and Extension Methods

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