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

VD>Поясняю. Ты пытаешся программировать на ООЯ не объектно-ориентированными методами. Отсюда и проблема. Не думай о структуре как о средстве сгриппировать переменные. Думай о ней как об объекте со своим состоянием, поведением и т.п.

Тогда позволь маленький совсем вопрос. Из этого следует, что ООЯ в принципе противопоказана идея просто сгруппировать переменные ? ИМХО все же слишком тяжелое утверждение.

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


VD>Шарп испоьзует области видимости дотнета. В одотнете типы могут объявляться только в простраствах имен, классах и струтурах. Так что даже в интерфейсе или перечислении другой тип описать нельзя.

Хм, а как же тогда в managed C++ можно структуры внутри функций описывать ? Тут кто-то сказал, что можно. Или нельзя все же ?

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А ты не мог бы объяснить причины прятать переменные от других ? Вопрос, естественно, риторический, ответ на него очевиден.
Ничего риторического в этом вопросе нет. Есть ровно одна причина "прятать" переменные: изоляция состояния. Когда я объявляю переменную внутри метода, я явно выражаю свое намерение контролировать ее состояние. И хочу иметь гарантию, что никто больше это состояние не изменит — и даже другой вызов этого же метода, выполняющийся в другом потоке, и даже этот же метод, рекурсивно вызванный в данном потоке.
PD>А ведь структуры в Шарпе — тоже в некотором смысле переменные, почему же для переменных допустима область видимости — функция или даже блок, а для типов — нет ?
Ничего подобного. Тип ни в каком смысле переменной не является. У него нет состояния! Поэтому нет никакой опасности, что кто-то что=то изменит во время выполнения (я сейчас не говорю о статических полях. Статическое поле — отдельная тема, и она в контексте method-scoped типов вообще смысла не имеет.).


PD> Чтобы его не было, придется в качестве имен классов GUID использовать
Тебе уже привели конвенцию, которая гарантирует 100% отсутствия конфликтов имен. Безо всяких гуидов.

PD>А основная причина, почему я этого хочу , вот в чем заключается. Есть хорошее правило — любое понятие (специально расплывчатый термин употребляю) должно существовать только там, где оно необходимо.
Ты, похоже, считаешь, что есть какие-то правила программирования, высеченные на скрижалях как данность. И те, кто их не придерживаются, попадут в ад.
На самом деле все не так. За каждым правилом стоит веская причина. И тупо переносить правила из одного контекста, где эта причина имела смысл, в другой контекст весьма рискованно. Правила, которое ты привел, не существует. Есть принципы дизайна по уменьшению связности. Но про них ты, судя по твоему примеру ниже, не знаешь.

PD>Переменная должна существовать только там , где она нужна, а поэтому параметр цикла никто не станет делать членом класса .
Это не аксиома. Есть совершенно определенная причина не делать параметр цикла членом класса. И даже она не всегда имеет место.
PD> Почему же тип может существовать только на уровне класса — не понимаю.
Потому, что для типа такой причины нет.
PD>Вот пример. Пусть есть класс

PD>class DeviceManager
PD>{
PD> public void Write() {...}
PD> public void Read() {...}
PD>};

PD>Работает он с неким устройством, умеет писать и читать, больше ничего. Устройство использует 20 структур при операциях чтения (т.е. с устройства читаются пакеты 20 разных видов) и 30 структур при операциях записи. Пакеты, подчеркиваю. Им глубокой логики не надо, из них класс с десятком функций делать не стоит, их просто сформировать надо и отослать. Из этих 20 и 30 структур лишь 5 являются общими для чтения и записи. Эти 5 имеет, конечно, смысл, вынести на уровень класса. А остальные 15 и 25 соответственно ИМХО лучше поместить внутрь Read или Write соответственно. Кстати, только Read или Write знает, как этот пакет правильно парсить/формировать.
Гм. По-моему, налицо чудовищная ошибка. Какова длина этих методов? Если там только структур использовано по 20 штук??? Ты привел пустые сигнатуры. На деле, полагаю, есть нормальный набор параметров, тип Write(byte[] data), так?
Наличие 20 структур означает, что протокол взаимодействия с устройством достаточно сложен. И отлаживать метод длиной в 500+ строк — ужасная перспектива.
Не надо разбивать класс на два. Надо резать метод. Чтобы каждый из методов был достаточно внятным. Типа:

public void Write(byte[] data)
{
  WriteStreamHeader  = PrepareHeader(_handle, data.Length);
    WriteHeader(_handle, header);
    int dataToSend = data.Length;
    int pos = 0;
    while(dataToSend > 0)
    {
      Chunk chunk = GetNextChunk(pos, data);
        dataToSend-= chunk.DataLength;
        pos+=chunk.DataLength;
        WriteDataChunk(_handle, chunk);
    } 
    WriteStreamTrailer trailer = PrepareTrailer(_handle, data);
    WriteTrailer(_handle, trailer);
}

В таком методе можно разобраться. Вспомогательные методы PrepareHeader, GetNextChunk, PrepareTrailer, WriteHeader, WriteDataChunk, WriteTrailer могут тоже быть устроены достаточно сложно.
Но обрати внимание — на этот раз структуры передаются между методами. Это означает, что твое наивное желание спрятать структуры внутрь невыполнимо.

PD>Позволю себе не согласиться. В С++ это есть и никому не мешает.
Видишь ли, в шарп не стали вносить все, что "не помешает".
PD>В Object Pascal тоже. Утверждать такое на основании лишь того, что в Шарпе MS это не реализовала я бы не стал.
А я бы стал. Но не потому, что в шарпе этого нет, а потому что никаких причин требовать поддержки method-scoped типов пока не прозвучало. Только рассказы про то, что структуры это то же самое, что переменные. Кстати, у нас за такие песни можно было на пересдачу уйти.

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

Простая группировка переменных достигается вообще безо всяких структур. Вот так:

#region Device Parameters
IntPtr handle;
int timeout;
DeviceControl controlWord;
#endregion

#region Math stuff
double integralTemp;
double upperBound, lowerBound;
double sensitivity;
#endregion

Ты математику учил? Тензор — это не просто несколько цыферок записанных в табличку. Это математический объект, описываемый своими компонентами. И это компоненты обязаны вести себя определенным образом при смене системы координат.

Точно так же и структура — это сущность, компоненты которой ведут себя согласованно. С точки зрения ООЯ это объект.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хм, а как же тогда в managed C++ можно структуры внутри функций описывать ? Тут кто-то сказал, что можно. Или нельзя все же ?
Из другого языка ты их не увидишь. А в жизни все может быть как угодно. Начиная от того, что компилятор может просто мапить такую структуру на набор стековых переменных и заканчивая генерацией специального невидимого типа на уровень класса.

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

S>Ты, похоже, считаешь, что есть какие-то правила программирования, высеченные на скрижалях как данность. И те, кто их не придерживаются, попадут в ад.

Sinclair, не стоит передергивать. Нигде я такого не говорил. Это просто практика всех, кто писал раньше на C++/Pascal. Об этом в любом учебнике по этим языкам написано. И то, что в С# этого нет, еще не означает, что это неверно. C# и .Net еще не все программирование .

S>На самом деле все не так. За каждым правилом стоит веская причина. И тупо переносить правила из одного контекста, где эта причина имела смысл, в другой контекст весьма рискованно. Правила, которое ты привел, не существует. Есть принципы дизайна по уменьшению связности. Но про них ты, судя по твоему примеру ниже, не знаешь.

Есть одно хорошее правило, которое звучит так : в определенных случаях надо действовать наперекор всем правилам. Потому что истина конкретна, а требования бывают различными. Если существеена максимальная скорость или объем памяти, то придется на все правила хорошего тона наплевать и делать вопрки им, но добиться результата. А с уменьшением связанности ты получишь массу накладных расходов и результат не будет достигнут. Это не значит, что я вообще против них. Но не все везде уместно.

PD>> Почему же тип может существовать только на уровне класса — не понимаю.
S>Потому, что для типа такой причины нет.

Ну нет так нет. Только одно добавим — в Шарпе нет. Потому как в других языках есть и используется.

S>Гм. По-моему, налицо чудовищная ошибка. Какова длина этих методов?

Не знаю, какая длина, но вот тебе реализация Write
switch(method)
{
case 1:
// формируем структуру A
// шлем на устройство
case 2:
// формируем структуру B
// шлем на устройство

и т.д.
}


S>Наличие 20 структур означает, что протокол взаимодействия с устройством достаточно сложен.

Как видишь, не очень

И отлаживать метод длиной в 500+ строк — ужасная перспектива.

В моем примере — не думаю

S>Не надо разбивать класс на два. Надо резать метод. Чтобы каждый из методов был достаточно внятным.

Ну что же, вот тебе пример. Порежь. Не буду возражать даже, если ты из этой функции 20 сделаешь. И размер у них небольшим совсем будет. Только тогда структуры A,B и т.д. неплохо бы внутри каждой из этих 20 функций соответственно и описать, а не выносить в класс.

S>Но обрати внимание — на этот раз структуры передаются между методами. Это означает, что твое наивное желание спрятать структуры внутрь невыполнимо.

А в моем примере очень даже выполнимо.

PD>>Позволю себе не согласиться. В С++ это есть и никому не мешает.
S>Видишь ли, в шарп не стали вносить все, что "не помешает".

ИМХО не стоит исходить из принципа, что то, что не внесли в Шарп есть истина в последней инстанции.

PD>>В Object Pascal тоже. Утверждать такое на основании лишь того, что в Шарпе MS это не реализовала я бы не стал.
S>А я бы стал. Но не потому, что в шарпе этого нет, а потому что никаких причин требовать поддержки method-scoped типов пока не прозвучало. Только рассказы про то, что структуры это то же самое, что переменные. Кстати, у нас за такие песни можно было на пересдачу уйти.

Опять передергивание. Я же четко сказал — "в некотором смысле". Т.е. они существуют в рантайме, имеют свои поля (static members) и т.д. Я же не утверждаю, что тип есть переменная в C#. Кстати, в Object Pascal я это вполне могу утверждать — там есть переменная типа тип, даже с наследованием. Можно создать такую переменную типа "тип базового класса", присвоить ей значение "тип производного класса", а потом создать экземпляр, и экземпляр будет,естественно, производного класса. Так что не торопись с решительными выводами...

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


S>Простая группировка переменных достигается вообще безо всяких структур. Вот так:

<skipped>

Теперь, пожалеуйста, присвой один набор Device Parameters другому.


S>Ты математику учил?

Было когда-то . Давно очень.

S>Точно так же и структура — это сущность, компоненты которой ведут себя согласованно. С точки зрения ООЯ это объект.

. А всех, кто с принципом "ООЯ доведенный до предела" не согласен — в ад!

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Хм, а как же тогда в managed C++ можно структуры внутри функций описывать ? Тут кто-то сказал, что можно. Или нельзя все же ?
S>Из другого языка ты их не увидишь.

Еще бы. Они же в функции описаны. Их не только из другого языка, их из другой функции того же класса не увидишь

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

S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Хм, а как же тогда в managed C++ можно структуры внутри функций описывать ? Тут кто-то сказал, что можно. Или нельзя все же ?
S>Из другого языка ты их не увидишь. А в жизни все может быть как угодно. Начиная от того, что компилятор может просто мапить такую структуру на набор стековых переменных и заканчивая генерацией специального невидимого типа на уровень класса.

Подумал еще раз над этим ответом. ИМХО вот здесь корень всей проблемы и кроется.

В .Net классы есть некоторая сущность эпохи рантайма, и довольно серьезная сущность. Если же оставить .Net в стороне и рассматривать unmanaged код, то в нем классы в рантайме или вообще не существуют (C++ без RTTI), либо ограниченно существуют (C++ с RTTI, Object Pascal). А поскольку C# специально заточен под .Net, MS и сделала в нем такое ограничение. Вот в этом и причина, а не в идейных соображениях. С С++ она такое сделать не могла — язык ей не принадлежит .
Ну а правильно это или нет — будущее покажет.
На этом и кончаю свое участие в этой дискуссии.

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

PD>Sinclair, не стоит передергивать. Нигде я такого не говорил. Это просто практика всех, кто писал раньше на C++/Pascal. Об этом в любом учебнике по этим языкам написано.
Что именно написано?

PD>Ну нет так нет. Только одно добавим — в Шарпе нет. Потому как в других языках есть и используется.
Приведи причину.

PD>Не знаю, какая длина, но вот тебе реализация Write
PD> switch(method)
PD>{
PD> case 1:
PD> // формируем структуру A
PD> // шлем на устройство
PD> case 2:
PD> // формируем структуру B
PD> // шлем на устройство

PD> и т.д.
PD>}

Да, совершенно верно. Тут вообще надо все рефакторить нафиг.

PD>В моем примере — не думаю
А я тебе говорю. Сам видел совершенно аналогичный код. Отлаживаться — очень трудно.

PD>Ну что же, вот тебе пример. Порежь. Не буду возражать даже, если ты из этой функции 20 сделаешь. И размер у них небольшим совсем будет. Только тогда структуры A,B и т.д. неплохо бы внутри каждой из этих 20 функций соответственно и описать, а не выносить в класс.
Примера пока нету. Есть некоторые намеки на его структуру. По ним я нутром чувствую, что как раз в данном случае я бы вообще разнес это на 20 классов.


PD>Опять передергивание. Я же четко сказал — "в некотором смысле". Т.е. они существуют в рантайме, имеют свои поля (static members) и т.д. Я же не утверждаю, что тип есть переменная в C#.
Это уже радует.
PD>Кстати, в Object Pascal я это вполне могу утверждать — там есть переменная типа тип, даже с наследованием.
Нет, не можешь. Ты вообще путаешь понятия тип и переменная. Переменная — это экземпляр типа. В Delphi есть семейство типов для метаклассов. Никакого отношения к переменным оно не имеет. Ни в каком смысле.

PD>Можно создать такую переменную типа "тип базового класса", присвоить ей значение "тип производного класса", а потом создать экземпляр, и экземпляр будет,естественно, производного класса. Так что не торопись с решительными выводами...
Поверь мне, про конструкцию class of в Delphi я знаю всё. Но это никак не делает типы и экземпляры эквивалентными.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Теперь, пожалеуйста, присвой один набор Device Parameters другому.
А вот это уже — сложная группировка. Если эти параметры присваиваются толпой, то это композитный объект, а не просто группа слабо связанных переменных.
S>>Точно так же и структура — это сущность, компоненты которой ведут себя согласованно. С точки зрения ООЯ это объект.

PD>. А всех, кто с принципом "ООЯ доведенный до предела" не согласен — в ад!
Нет, зачем в ад. Просто, например, самолет водить почему-то доверяют только тем, кто понимает, как им управлять. И пытаться говорить, что "а вот на подводной лодке я не так все делал", и что "отсутствие на самолете герметичных переборок между отсеками — это отстой", и что "глупо отрицать полезность переборок только потому, что боинг их не делает" — это, мягко говоря, неразумно.
Есть великое множество различных технологий программирования. Как только ты приходишь в какую-то из них, ты получаешь набор возможностей и ограничений. В хорошо продуманной технологии все сбалансировано. Бессмысленно апеллировать к другой технологии при обсуждении этой. Потому, что возможности технологии А были введены для решения проблем технологии А. В технологии Б этих возможностей может не быть не потому, что Б — убогость. А потому, что либо проблем А в этой технологии вообще нет, либо они решаются другими средствами.
В реальности, человек, который возьмется писать на С# в стиле C (см. пример с switch в методе Write), будет в ближайшем будущем уволен.

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

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

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

Честно сказать, мне эта дискуссия порядком надоела. Теперь уж точно в последний раз. Времени нет на эти пустопорожние споры.

PD>>Sinclair, не стоит передергивать. Нигде я такого не говорил. Это просто практика всех, кто писал раньше на C++/Pascal. Об этом в любом учебнике по этим языкам написано.
S>Что именно написано?

Почитай сам любой учебник.

PD>>Ну нет так нет. Только одно добавим — в Шарпе нет. Потому как в других языках есть и используется.
S>Приведи причину.

Там она и приводится.


S>Да, совершенно верно. Тут вообще надо все рефакторить нафиг.

Успехов!

PD>>В моем примере — не думаю
S>А я тебе говорю. Сам видел совершенно аналогичный код. Отлаживаться — очень трудно.

PD>>Ну что же, вот тебе пример. Порежь. Не буду возражать даже, если ты из этой функции 20 сделаешь. И размер у них небольшим совсем будет. Только тогда структуры A,B и т.д. неплохо бы внутри каждой из этих 20 функций соответственно и описать, а не выносить в класс.
S>Примера пока нету. Есть некоторые намеки на его структуру. По ним я нутром чувствую, что как раз в данном случае я бы вообще разнес это на 20 классов.

Прекрасно. 20 классов, несколько десятков свойств и методов, интерфейс между ними и т.д. 30 сотраниц документации потом. И все это ради того, чтобы 20 структур сформировать и на устройство отправить.
Может, это все и верно, может, именно так и надо сейчас. Не знаю. Но если это именно так — неудивительно, что все это потом работает очень медленно , а памяти ест немеряно. Зато принципы ООП тут полностью в порядке.


PD>>Опять передергивание. Я же четко сказал — "в некотором смысле". Т.е. они существуют в рантайме, имеют свои поля (static members) и т.д. Я же не утверждаю, что тип есть переменная в C#.
S>Это уже радует.

Я тоже рад, что ты это наконец понял.

PD>>Кстати, в Object Pascal я это вполне могу утверждать — там есть переменная типа тип, даже с наследованием.
S>Нет, не можешь. Ты вообще путаешь понятия тип и переменная. Переменная — это экземпляр типа. В Delphi есть семейство типов для метаклассов. Никакого отношения к переменным оно не имеет. Ни в каком смысле.

Опять двадцать пять. Я эе , кажется, ясно дал понzть, что говоря о типе, я имею в виду то, что это нечто, существующее в рантайме. Ты их называешь переменными метаклассов я — типами как переменными — от этого суть не изменится. Может, я не совсем точный термин употребил, но понять ИМХО можно было. Или ты впрямь думаешь, что я после 25 лет программирования определение (тип) от куска памяти (переменная) отличить не могу ?

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

PD>Может, это все и верно, может, именно так и надо сейчас. Не знаю. Но если это именно так — неудивительно, что все это потом работает очень медленно , а памяти ест немеряно. Зато принципы ООП тут полностью в порядке.
Да-да, а все из-за того, что нельзя декларировать тип в методе.

PD> Или ты впрямь думаешь, что я после 25 лет программирования определение (тип) от куска памяти (переменная) отличить не могу ?
Конечно. А что я еще должен думать о человеке, который говоит, что структура в некотором смысле — переменная? И в качестве иллюстрации приводит мне метаклассы Delphi?

Здравствуйте, Pavel Dvorkin, Вы писали:
А в Object Pascal есть даже переменные типа "тип", правда, как они реализованы, я не знаю.
http://www.rsdn.ru/Forum/?mid=561976

Автор: Serginio1
Дата: 09.03.04

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

PD>Тогда позволь маленький совсем вопрос. Из этого следует, что ООЯ в принципе противопоказана идея просто сгруппировать переменные ? ИМХО все же слишком тяжелое утверждение.
1. Сгруппированные переменные это либо:
a) Объект с типом что вам не нравится
б) Массив переменных(но он в нет тоже объект, и я думаю, вам тоже не понравится).
2. Ничего быстрее ассемблера никто не придумал. За абстракцию надо платить.

С уважением, Gleb.

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


GZ>2. Ничего быстрее ассемблера никто не придумал. За абстракцию надо платить.

Эх, скажи как на C# на asm перейти .

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

PD>Эх, скажи как на C# на asm перейти .

Легко. System.Reflection.Emit — туземный ассемблер

С уважением, Gleb.

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

GZ>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Эх, скажи как на C# на asm перейти .

GZ>Легко. System.Reflection.Emit — туземный ассемблер

Thanks. Я предпочитаю ассемблер белых людей

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

PD>Тогда позволь маленький совсем вопрос. Из этого следует, что ООЯ в принципе противопоказана идея просто сгруппировать переменные ?

Именно! Оно же бездумное! А если оно не бездумное, то появляется новая абстракция для выражения которой ООЯ очень подходит.

PD>ИМХО все же слишком тяжелое утверждение.

Ты просто привык к тому, что С++ это на 50% С. Шарп же специально проектировался так, чтобы стимулировать писать в ОО-стиле.