Здравствуйте, 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>В общем, чем дальше читаю эту тему, тем больше понимаю, что проблем от МН больше чем приемуществ. А ведь еще не давно я так не думал.
Не нарвится не используй никто не настаивает. Я например в ходе практики выяснил все плюсы, минусы и подводные грабли в М-Н. Поэтому юзаю там где считаю нужным. Чужие теоретические рассуждения о М-Н, мне совершенно фиолетовы.
Здравствуйте, 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
Здравствуйте, WoldemaR, Вы писали:
WR>Полиморфное разделение объектов графического редактора, которое демонстрируется в каждом учебнике по ООП — тупиковый путь. индустрия ( -какое слово то!!!) от него уже давно отказалась.
Не могли бы Вы привести ссылок на тему отказа индустрии от ПРО?
Здравствуйте, A.Lokotkov, Вы писали:
AL>Не могли бы Вы привести ссылок на тему отказа индустрии от ПРО?
Вот ссылок привести немогу. Но если Вы посмотрите последние версии векторных графических редакторов: типа Corel, Flash, Xara, и т.п. то заметите что существует возможность трансформации объекта из одного "типа" в другой "тип", т.е. все объекты равнофункциональны.
А чему нас учили?
class DrawObject{};
class Line : DrawObject{};
class Circle : DrawObject{};
class Square : DrawObject{};
WR>>Несмотря на то, что мазохизм иногда встречается в самых неожиданных формах, это не является поводом принимать извращения за правило.
DG>А четко обосновать почему это так, сможете? или только можете общие фразы выдавать?
Понимаете в чём дело.
Если вам нравится выполнение рутинной работы, а у вашего начальства достаточно денег для использования трудоёмких текнологий, то кто я такой чтобы говорить Вам, что это плохо?
Здравствуйте, VladD2, Вы писали:
VD>Ты не понял. Он же сказал "индустрия уже отказалась". Просто она сказала это толко ему одному. А мы просто еще не в крусе.
VladD2, да ты не комплексуй. у каждого человека есть слабые и сильные стороны.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, DarkGray, Вы писали:
DG>>А четко обосновать почему это так, сможете? или только можете общие фразы выдавать?
VD>Ты не понял. Он же сказал "индустрия уже отказалась". Просто она сказала это толко ему одному. А мы просто еще не в крусе.
Имхо, индустрия не должна быть авторитетом для разработчика.
Даже полный успех в чужой дхарме бесполезен — к своей устремляйся (Бхагават Гита)
К тому же далеко не всегда индустрия шагает верным путем. Взять к примеру ХМЛ, средняя буква означает маркап, т.е. для разметки предназначен. Но досадному недоразумению ХМЛ стали юзать везде, причем как обычно в самых извращенных формах.
Здравствуйте, 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-ов, но я все равно шизею от дорогой редакции... Что они творят с моим любимым языком?
Здравствуйте, mrozov, Вы писали:
M>Конечно, так красиво все только для stateless mixin-ов, но я все равно шизею от дорогой редакции... Что они творят с моим любимым языком?
Это сахар, а не миксины. Этим баловством нельзя реализовавать интерфейсы. Короче толку мало.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
M>>Конечно, так красиво все только для stateless mixin-ов, но я все равно шизею от дорогой редакции... Что они творят с моим любимым языком? WH>Это сахар, а не миксины. Этим баловством нельзя реализовавать интерфейсы. Короче толку мало.
Толку много, но решается другая задача.
И вот еще что... Хорошо, что они творят хотя бы это с нашим любимым языком.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
— интерфейс содержит часть реализации по умолчанию. Очень похоже на то, как это сделано в Хаскелле — можно реализовать некий кусок интерфейса, а остальной кусок реализуется автоматически.