А что за проблему ты пыташся решить? Я подобный код писал только в генераторе кода когда часть класса генерировалась автоматом. Но и то сейчас можно пользоваться portial-классами.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>А что мешает писать так:
Там не всё так просто. класс B в свою осередь реализует другие не мои интерфейсы. Если по-подробнее то так
interface IOwfulInmterface
{
int MethodWithOwfulSignature(owful_parameters)
}
class VeryGoodClass1
{
public:
int MethodWithUnderstandableParameters(understandable_parameters);
}
class VeryGoodClass2
{
public:
int MethodWithUnderstandableParameters(understandable_parameters);
}
class VeryGoodClass3
{
public:
int MethodWithUnderstandableParameters(understandable_parameters);
}
template <typename T>
class Proxy : public T, public IOwfulInterface
{
public:
int MethodWithOwfulSignature(owful_parameters)
{
MethodWithUnderstandableParameters(understandable_parameters);
}
}
и соответсвенно
interface IOwfulInterface
{
int MethodWithOwfulSignature(owful_parameters);
}
interface IVeryGood
{
int MethodWithUnderstandableParameters(understandable_parameters);
}
public class VeryGoodBase : IOwfulInterface
{
public int MethodWithOwfulSignature()
{
((IVeryGood)this).MethodWithUnderstandableParameters(understandable_parameters);
}
}
public class VeryGood1 : VeryGoodBase, IVeryGood
{
public int MethodWithUnderstandableParameters(understandable_parameters);
}
public class VeryGood2 : VeryGoodBase, IVeryGood
{
public int MethodWithUnderstandableParameters(understandable_parameters);
}
public class VeryGood3 : VeryGoodBase, IVeryGood
{
public int MethodWithUnderstandableParameters(understandable_parameters);
}
Внутри Proxy/VeryGoodBase::MethodWithOwfulSignature очень много общей логики.
То что ты написал это тоже хорошо, но интерфесов IVeryGood на самом деле несколько и не все их них всегда реализуются.
К тому же основная проблема для меня в том, что все проверки уходят в run-time и я понятия не имею реализовал ли класс-потомок всё что от него хотел базовый класс пока сам это ручками не проверю или пока не прогоняю тест, а он обширный и это просто неудобно.
Здравствуйте, adontz, Вы писали:
A>То что ты написал это тоже хорошо, но интерфесов IVeryGood на самом деле несколько и не все их них всегда реализуются. A>К тому же основная проблема для меня в том, что все проверки уходят в run-time и я понятия не имею реализовал ли класс-потомок всё что от него хотел базовый класс пока сам это ручками не проверю или пока не прогоняю тест, а он обширный и это просто неудобно.
Я не очень понял — ведь можно же написать несколько абстрактных методов?
Проверять реализацию будет компилятор в compile-time, а не Вы в в run-time.
public abstract class VeryGoodBase:
IOwfulInterface1, IOwfulInterface2, IOwfulInterface3, IOwfulInterface4, IOwfulInterface5,
IVeryGood1, IVeryGood2, IVeryGood3, IVeryGood4, IVeryGood5
{
public abstract int MethodWithUnderstandableParameters1(...1);
public abstract int MethodWithUnderstandableParameters2(...2);
public abstract int MethodWithUnderstandableParameters3(...3);
public abstract int MethodWithUnderstandableParameters4(...4);
public abstract int MethodWithUnderstandableParameters5(...5);
public int MethodWithOwfulSignature1(...1)
{
this.MethodWithUnderstandableParameters1(understandable_parameters1);
}
public int MethodWithOwfulSignature2(...2)
{
this.MethodWithUnderstandableParameters2(understandable_parameters2);
}
public int MethodWithOwfulSignature3(...3)
{
this.MethodWithUnderstandableParameters3(understandable_parameters3);
}
public int MethodWithOwfulSignature4(...4)
{
this.MethodWithUnderstandableParameters4(understandable_parameters4);
}
public int MethodWithOwfulSignature5(...5)
{
this.MethodWithUnderstandableParameters5(understandable_parameters5);
}
}
public abstract class VeryGoodBase:
IOwfulInterface1, IOwfulInterface2, IOwfulInterface3, IOwfulInterface4, IOwfulInterface5,
IVeryGood1, IVeryGood2, IVeryGood3, IVeryGood4, IVeryGood5
{
public abstract int MethodWithUnderstandableParameters1(...1);
public abstract int MethodWithUnderstandableParameters2(...2);
public abstract int MethodWithUnderstandableParameters3(...3);
public abstract int MethodWithUnderstandableParameters4(...4);
public abstract int MethodWithUnderstandableParameters5(...5);
public int MethodWithOwfulSignature1(...1)
{
this.MethodWithUnderstandableParameters1(understandable_parameters1);
}
public int MethodWithOwfulSignature2(...2)
{
this.MethodWithUnderstandableParameters2(understandable_parameters2);
}
public int MethodWithOwfulSignature3(...3)
{
this.MethodWithUnderstandableParameters3(understandable_parameters3);
}
public int MethodWithOwfulSignature4(...4)
{
this.MethodWithUnderstandableParameters4(understandable_parameters4);
}
public int MethodWithOwfulSignature5(...5)
{
this.MethodWithUnderstandableParameters5(understandable_parameters5);
}
}
Проблема в том что иногда я не хочу реализовывать методы MethodWithOwfulSignature4 и MethodWithOwfulSignature5 если то что они делают не поддерживается. Именно НЕ реализовывать, а не заглушки писать. Потому как методов на самом деле огромное количество и писать для 10 объектов которым нужно 3-4 метода по 50 заглушек не охота.
Наследование от параметра шаблона+вызов функции если она есть с Си++ решали эту проблему. А тут я какой-то хернёй маюсь
Здравствуйте, adontz, Вы писали:
A>Проблема в том что иногда я не хочу реализовывать методы MethodWithOwfulSignature4 и MethodWithOwfulSignature5 если то что они делают не поддерживается. Именно НЕ реализовывать, а не заглушки писать. Потому как методов на самом деле огромное количество и писать для 10 объектов которым нужно 3-4 метода по 50 заглушек не охота. A>Наследование от параметра шаблона+вызов функции если она есть с Си++ решали эту проблему. А тут я какой-то хернёй маюсь
А что если все заглушки всего один раз написать?
public abstract class VeryGoodBase: ...
{
public virtual int MethodWithUnderstandableParameters1(...1){заглушка1;}
public virtual int MethodWithUnderstandableParameters2(...2){заглушка2;}
public virtual int MethodWithUnderstandableParameters3(...3){заглушка3;}
public virtual int MethodWithUnderstandableParameters4(...4){заглушка4;}
public virtual int MethodWithUnderstandableParameters5(...5){заглушка5;}
...
public int MethodWithAwfulSignature1(...1)
{
this.MethodWithUnderstandableParameters1(understandable_parameters1);
}
public int MethodWithAwfulSignature2(...2)
{
this.MethodWithUnderstandableParameters2(understandable_parameters2);
}
...
}
А потом, если не хочешь 50 методов переопределять — так и не переопределяй.
Кстати я у себя на прошлой неделе именно так и сделал, вот смотрите:
public abstract class AbstractSpeechStream:
SpeechLib.ISpStreamFormat,
SpeechLib.ISpeechBaseStream,
SpeechLib.ISequentialStream,
SpeechLib.IStream
{
//---SpeechLib.ISpStreamFormat ----------------------------------------------------------------------------------public virtual void GetFormat (ref System.Guid pguidFormatId, System.IntPtr ppCoMemWaveFormatEx) {}
//- SpeechLib.ISpeechBaseStream ----------------------------------------------------------------------------------public virtual int Read (out object buffer, int numberOfBytes) {buffer = null; return 0;}
public virtual object Seek (object position, SpeechLib.SpeechStreamSeekPositionType origin) {return null;}
public virtual int Write (object obj) {return 0;}
public virtual SpeechLib.SpAudioFormat Format{get{return null;} set {}}
//---SpeechLib.ISequentialStream ----------------------------------------------------------------------------------public virtual void RemoteRead (out byte b0, uint requestByteCount, out uint readedByteCount) {b0 = 0; readedByteCount = 0;}
public virtual void RemoteWrite (ref byte b0, uint requestByteCount, out uint writtenByteCount) {writtenByteCount = 0;}
//---SpeechLib.IStream---------------------------------------------------------------------------------------------public virtual void RemoteSeek (SpeechLib._LARGE_INTEGER dlibMove, uint dwOrigin, out SpeechLib._ULARGE_INTEGER plibNewPosition) {plibNewPosition.QuadPart = (ulong)dlibMove.QuadPart;}
public virtual void Clone (out SpeechLib.IStream newStream) {newStream = null;}
public virtual void Commit (uint grfCommitFlags) {}
public virtual void RemoteCopyTo (SpeechLib.IStream pstm, SpeechLib._ULARGE_INTEGER cb, out SpeechLib._ULARGE_INTEGER pcbRead, out SpeechLib._ULARGE_INTEGER pcbWritten) {pcbRead = new SpeechLib._ULARGE_INTEGER(); pcbWritten = new SpeechLib._ULARGE_INTEGER();}
public virtual void Revert () {}
public virtual void SetSize (SpeechLib._ULARGE_INTEGER libNewSize) {}
public virtual void Stat (out SpeechLib.tagSTATSTG statstg, uint grfStatFlag) {statstg = new SpeechLib.tagSTATSTG();}
public virtual void LockRegion (SpeechLib._ULARGE_INTEGER libOffset, SpeechLib._ULARGE_INTEGER cb, uint dwLockType) {}
public virtual void UnlockRegion (SpeechLib._ULARGE_INTEGER libOffset, SpeechLib._ULARGE_INTEGER cb, uint dwLockType){}
}
А потом отнаследовался от AbstractSpeechStream в AudioInput и в AudioOutput
в которых переопределил только RemoteSeek, GetFormat
и соответственно RemoteRead либо RemoteWrite.
На переопределение остальных методов забил. Вот и все дела...
Здравствуйте, VladD2, Вы писали:
A>>А конкретно с методами GetGuidProperty SetGuidProperty GetProperty SetProperty интерфейса IVsHierarchy VD>Это же КОМ. Причем тут дженерики и наследование?
adontz,
ПК>> А почему бы не попробовать C++/CLI? В нем есть полноценные шаблоны ПК>> C++.
a> Ну и где скачать его компилятор? Только чтоб не beta unstable a> prerelease candidate preview.
Мне показалось, что ты generics использовал из C# 2.0, который в том же
статусе, что и C++/CLI?
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Мне показалось, что ты generics использовал из C# 2.0, который в том же статусе, что и C++/CLI?
Нет Я сказал, что мне нехватает шаблонов от параметров которых можно наследоваться. Разве от параметров дженериков можно наследоваться? АФАИК нет. Так что дженерики идут лесом.
Я на 2003-й студии. Framework 1.1
Я собственно не столько решение ищу, сколько поплакаться захотел
Здравствуйте, adontz, Вы писали:
A>>>Воюю с MS'ными интерфейсами. Меняю страшную иерархию на не очень страшную. VD>>А конкретно?
A>А конкретно с методами GetGuidProperty SetGuidProperty GetProperty SetProperty интерфейса IVsHierarchy
И зачем тебе понадобилось наследование от параметра шаблона?
Здравствуйте, AndrewVK, Вы писали:
A>>А конкретно с методами GetGuidProperty SetGuidProperty GetProperty SetProperty интерфейса IVsHierarchy AVK>И зачем тебе понадобилось наследование от параметра шаблона?
Ну как. Шаблонный класс реализует IVsUIHierarchy и перенаправляет подкорректированные вызовы параметру шаблона (который по ходу базовый класс).
Да, это в принципе можно заменить вызовом виртуального метода, но идеологически это не правильно. Виртуальное наследование подразумевает множество наследований неизвестно кем, а тут параметр шаблона выступает не в качестве расширителя, а в качестве политики поведения.
То есть я не расширяю базовую реализацию IVsUIHierarchy несколькими способами, я создаю её с разными политиками поведения.
То что я написал именно так как я написал, а не использовал казалось бы более очевидные виртуальные методы, результат того что я пытался выразить своё видение архитектуры и показывает что в данном конкретном случае моё видение архитектуры классов языком не выражалось. Холивар по поводу "Вот в .Net нормальных шаблонов нету, вай-вай-вай!" я не разводить не собираюсь, просто было интересно насколько часто другие попадали в такую же ситуацию.
Ну и производительность конечно вообще говоря разная получается, хотя вызов виртуального метода это не катастрофа, но зато потенциал оптимизации гораздо выше. Но в контексте текущей задачи это меня вообще не беспокоит — студия сама по себе довольно тормозная штука.
Здравствуйте, adontz, Вы писали:
A>Ну как. Шаблонный класс реализует IVsUIHierarchy и перенаправляет подкорректированные вызовы параметру шаблона (который по ходу базовый класс).
Вот и интересно, что это за подкорректированные вызовы. Что там корректировать?
A>То есть я не расширяю базовую реализацию IVsUIHierarchy несколькими способами, я создаю её с разными политиками поведения.
Т.е. тебе фактически нужны миксины. Ну так с этого и надо было начинать. Реализация миксинов на базе плюсовых шаблонов тоже далека от идеала. И, да, миксинов в C# не хватает.
A>Ну и производительность конечно вообще говоря разная получается, хотя вызов виртуального метода это не катастрофа, но зато потенциал оптимизации гораздо выше.
Замедление виртуальных методов на фоне интеропа с СОМом? Не смешите мои тапочки.
Здравствуйте, AndrewVK, Вы писали:
A>>Ну как. Шаблонный класс реализует IVsUIHierarchy и перенаправляет подкорректированные вызовы параметру шаблона (который по ходу базовый класс). AVK>Вот и интересно, что это за подкорректированные вызовы. Что там корректировать?
Например есть 4 своства ассоциированных с именем: VSHPROPID_SaveName, VSHPROPID_Caption, VSHPROPID_Name, VSHPROPID_EditLabel. В моём случае они все обозначают одно и то же. Мне надо обращения к ним перенаправлять на одно и тоже свойство.
A>>То есть я не расширяю базовую реализацию IVsUIHierarchy несколькими способами, я создаю её с разными политиками поведения. AVK>Т.е. тебе фактически нужны миксины. Ну так с этого и надо было начинать. Реализация миксинов на базе плюсовых шаблонов тоже далека от идеала. И, да, миксинов в C# не хватает.
Ну можно и миксинами назвать, хотя термин policy мне как-то ближе.
A>>Ну и производительность конечно вообще говоря разная получается, хотя вызов виртуального метода это не катастрофа, но зато потенциал оптимизации гораздо выше. AVK>Замедление виртуальных методов на фоне интеропа с СОМом? Не смешите мои тапочки.
Нет, я вообще. Говорю же, что в контексте текущей задачи меня не это волнует, но вообще говоря это тоже имеетм есто быть.
Здравствуйте, adontz, Вы писали:
A>Например есть 4 своства ассоциированных с именем: VSHPROPID_SaveName, VSHPROPID_Caption, VSHPROPID_Name, VSHPROPID_EditLabel. В моём случае они все обозначают одно и то же. Мне надо обращения к ним перенаправлять на одно и тоже свойство.
Здравствуйте, AndrewVK, Вы писали:
A>>Например есть 4 своства ассоциированных с именем: VSHPROPID_SaveName, VSHPROPID_Caption, VSHPROPID_Name, VSHPROPID_EditLabel. В моём случае они все обозначают одно и то же. Мне надо обращения к ним перенаправлять на одно и тоже свойство. AVK>И все таки идеи я уловить не могу.
По сути идея такая
public int SetProperty(uint itemID, int propID, object var)
{
switch (propID)
{
case VSHPROPID_SaveName:
case VSHPROPID_Caption:
case VSHPROPID_Name:
case VSHPROPID_EditLabel:
((IVsHierarchyImplemetation)this).Name[itemID] = (string)var;
break;
}
return ResultCom.S_OK;
}
public int GetProperty(uint itemID, int propID, out object var)
{
switch (propID)
{
case VSHPROPID_SaveName:
case VSHPROPID_Caption:
case VSHPROPID_Name:
case VSHPROPID_EditLabel:
var = ((IVsHierarchyImplemetation)this).Name[itemID];
break;
}
return ResultCom.S_OK;
}
Здравствуйте, adontz, Вы писали:
A>По сути идея такая A>
A>public int SetProperty(uint itemID, int propID, object var)
A>{
A> switch (propID)
A> {
A> case VSHPROPID_SaveName:
A> case VSHPROPID_Caption:
A> case VSHPROPID_Name:
A> case VSHPROPID_EditLabel:
A> ((IVsHierarchyImplemetation)this).Name[itemID] = (string)var;
A> break;
A> }
A> return ResultCom.S_OK;
A>}
A>public int GetProperty(uint itemID, int propID, out object var)
A>{
A> switch (propID)
A> {
A> case VSHPROPID_SaveName:
A> case VSHPROPID_Caption:
A> case VSHPROPID_Name:
A> case VSHPROPID_EditLabel:
A> var = ((IVsHierarchyImplemetation)this).Name[itemID];
A> break;
A> }
A> return ResultCom.S_OK;
A>}
A>
Какой то код не очень. Не лучше ли закатать в хеш набор делегатов, сформированный на базе рефлекшена?
P.S. Коль скоро взялся за создание своего типа проекта, погляди VSIP SDK для 2005 студии, там готовые обертки есть, может ничего писать не придется.
Здравствуйте, AndrewVK, Вы писали:
AVK>Какой то код не очень. Не лучше ли закатать в хеш набор делегатов, сформированный на базе рефлекшена?
Лучше конечно. Я просто идею показал — что во что транслирую, ты же её не понял. На самом деле этот код вообще не скомпилируется — надо долго колдовать пока значение VSHPROPID к uint приведётся.
AVK>P.S. Коль скоро взялся за создание своего типа проекта, погляди VSIP SDK для 2005 студии, там готовые обертки есть, может ничего писать не придется.
VS2005 это конечно хорошо, но всё и на 2003 должно работать. А вдруг там в обёртке C#2.0 и дженерики? Оно мне надо?
A>и писать для 10 объектов которым нужно 3-4 метода по 50 заглушек не охота. A>Наследование от параметра шаблона+вызов функции если она есть с Си++ решали эту проблему. А тут я какой-то хернёй маюсь
Мне кажется проблему легко решила бы генерация кода или как предлагал АВК банальный мапинг на делегатах.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>Мне показалось, что ты generics использовал из C# 2.0, который в том же статусе, что и C++/CLI? > > Статус тот же но вот стабилность явно разная. Шарп 2 с конца 2003 года стабилен. C++/CLI же скорее всего по традиции будет глючить и после релиза.
По какой традиции? О чем речь-то? Может, примеры приведешь, или какие-то другие факты?
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>По какой традиции? О чем речь-то? Может, примеры приведешь, или какие-то другие факты?
У МС традиция такая забивать на МС++. Первая версия глючила не по детски. В 1.1 поправили многое, но проблем отсалось хоть отбавляй. Мои попытки повозиться с С++Кли показали, что традиции сохраняются. Конечно может МС и удастся вытянуть С++Кли, но верется в это не сильно. Вот поддержку ЮМЛ-я она для него уже викинули.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
ПК>> По какой традиции? О чем речь-то? Может, примеры приведешь, или ПК>> какие-то другие факты?
V> У МС традиция такая забивать на МС++. Первая версия глючила <...>
Это не пример того, как глючит C++/CLI: Managed Extensions for C++ !=
C++/CLI в т.ч. и по отношению компании к своему детищу.
V> Мои попытки повозиться с С++Кли показали, что традиции сохраняются.
Вот я и спрашиваю о примерах, которые ты пока так и не привел (ни одного).
V> Вот поддержку ЮМЛ-я она для него уже викинули.
Это не относится к "глючить", напротив, чтоб не глючило, т.к. недостаточно
ресурсов, отложили до следующего релиза.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
