Re[14]: Структура внутри функции - Философия программирования

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

PD>

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

PD>struct MP
PD>{
PD> int x,y,z;
PD> float weight;
PD>};

Прекрасно. Все то же самое пишем на C# 1<->1.
PD>и все, пламенный привет. Никакие методы мне не нужны. Либо 4 переменные, либо одна MP. И не хочу я, чтобы эта MP была видна где-то еще. Потому как вообще-то в проекте все координаты вещественными должны быть (такие требования), а вот здесь мне нужны 3 целые координаты и вещественный вес.
Ты не мог бы пояснить подробнее причины прятать структуру от остальных? Я вижу две проблемы:
1. Есть риск конфликта имен.
Ну да, если везде применять такие чудные имена типов, как MP, P, P1, P3F — спид, ребята, неизбежен. Уже при декларации приватного типа в пределах класса мы сводим риск конфликта имен к минимуму.
2. Есть риск того, что кто-то использует структуру без твоего ведома.
Вот этого аргумента я вообще понять не могу. Ну, использует, и что? Какой вред-то от этого произойдет? Кроме того кто он, этот вредитель? Он почему-то имеет доступ к твоим исходникам наравне с тобой (потому как использовать эту структуру можно только в пределах твоего же класса). Если ему надо — он вынесет структуру за пределы метода и использует.
Если ты боишься, что он перепутает ее со структурой, которую надо было использовать, то у меня два вопроса:
— зачем ты допускаешь дебилов править код твоего класса? Это может принести настолько большие убытки, что лучше сразу застрелиться
— почему код не сопровождается внятной документацией или хотя бы комментариями, которые описывают твое намерение использовать этот тип только в пределах функции.

PD>Если я структур заводить не буду, а просто опишу 4 переменные

PD> int x1,y1,z1;
PD> float weight1;

PD>то, я полагаю, ты не будешь меня упрекать в том, что я нарушил правила хорошего стиля тем, что не создал класс. Так ведь можно дойти до абсурда и потребовать отдельный класс для каждой переменной.
А зачем доходить до абсурда? Что, здравый смысл уехал в отпуск? Если у тебя есть группа переменных, изменяющихся согласованно, то имеет великий смысл выделить их в некую структуру. Хотя бы потому, чтобы читателю было понятна эта группировка. Отличия структов от классов минимальны в плюсах, и, хотя в дотнете они заметнее, обсуждать их смысла не имеет.

PD>А я бы предпочел упростить все это
PD>MP mp1, mp2;
PD>mp2 = mp1;
PD>И что же здесь криминального ? И обязательно ли здесь огород (класс т.е. городить) ?
Нет. Используй struct.

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

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, 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?

... << RSDN@Home 1.1.4 stable rev. 510>>

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

PD>Кто помешает создавать экземпляры этого класса где бы то ни было ? А я хочу только в данной функции
Таких параноидальных типов видимости в .NET не бывает.

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

PD>Угу. При том. что по смыслу задачи это один объект, надо искусственно его разбить на ряд классов просто потому, что один человек за отведенное время справиться с написанием кода не в состоянии. В этих классах придется определить как свойства всякие внутренние поля (чтобы классы друг с другом могли взаимодействовать) при том, что по смыслу задачи эти поля super private

и к ним вообще никто постронний доступ иметь не должен. Нет, мне эта идея не нравится.

Ужасно. Просто чудовищно, как эти русские говорят безо всяких артиклей! Вот я всегда употребляю артикли. А тут предлагается выводить определенность/неопределенность подлежащего из контекста. Нет, мне эта идея не нравится.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

PD>Не хочу я писать в плохом стиле. Я наоборот хочу в хорошем писать

PD>Ситуация. Пишу я функцию. В ней штук 10 переменных, описывающих некоторый внутренний для этой функции объект (слово объект в общечеловеческом смысле, а не в смысле языка). В соответствии с правилами хорошего стиля стоит из них создать структуру, чтобы обращаться к этим переменным как к некоторому единому целому. Ну хоть скопировать их все в другой набор таких же переменных (для другого объекта).
Десять переменных? Можно подумать и о классе. Пуская даже private и с одной функцией.

PD>Все это интересно в данной функции. За пределами этой функции такая структура никому не нужна, да и вообще желательно, чтобы о ней никто не знал, потому как дело это сугубо внутреннее для этой функции. А получается, что сделать такое невозможно.
Тип в Net больше чем размеченная область памяти доступная компилятору в определенных границах. Любой тип описывается в метаданных, и с ним можно работать через рефлекшин. А для этого важны правила именования. А в именование идет namespace.имя_типа.
Как выход, могу предложить следующий алгоритм:
1. Выделить структуру в класс.
2. Структуру определить как private
3. Переназвать структуру(например имя_функции_имя_структуры)
Вроде бы и стиль будет достаточно хорош.

А вообще, говорить что можно перевести с языка на язык без рефакторинга, нельзя. Это, конечно, не Лисп, но идеалогия языков различается.

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

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

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

PD>>Кто помешает создавать экземпляры этого класса где бы то ни было ? А я хочу только в данной функции
Mab>Таких параноидальных типов видимости в .NET не бывает.

Я бы все же просил придерживаться политкорректности. Такие типы видимости существуют в Паскале, С/C++, из чего не следует, что эти языки являются параноидальными.

2 Автор
Используй C#3

Там есть неименованные структуры

А если серьёзно:

Если да — как лучше скалькировать это с С++ на С# ? Вариант выноса стуктуры на уровень класса не годится — в функции g на С++ может быть описана другая стуктура с тем же именем.

Возвращай Hashtable, если возможно

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

PD>А вот это опросил бы подробнее прокомментировать. Насколько я понимаю, такое объявление позволит мне создавать экземпляры этого объекта где бы то ни было внутри класса, так ?

PD>Предположим, что класс огромный по размеру кода (я сказал "предположим", это не надо сейчас обсуждать с точки зрения хорошего стиля программирования), а поэтому его разработка поручена нескольким человекам. Им по ходу работы нужно создавать структуры (пусть даже не классы!), чтобы просто не иметь сотен переменных. Значит, им придется согласовывать друг с другом имена этих структур, так ? Ведь описания этих структур надо выносить на уровень класса ?
PD>Или я что-то не так понял ?
Тут вопрос философский. .NET как платформа для разработки заодно подразумевает некоторый стиль написания кода под нее. Свойство это выражено намного сильнее, чем, скажем, в C++, где одно и то же можно описать десятью различными способами, а потом еще удивляться, отчего сосед делает это 11-м. Платформа подразумевает этот стиль временами весьма навязчиво, так что написание кода не следуя ему становится довольно затруднительным.

Поэтому не стоит удивляться, отчего платформа не дает и дальше писать код в старом стиле, делая этот "огромный" класс еще более огромным. Рефакторинг поможет решить эту проблему, благо в C# инструменты для него имеются (в отличие от C++ и Pascal).

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

PD>Вот это уже черт знает, что такое. Получается, что внутри функции и набор констант определить нельзя!
Нельзя определять новые типы. Константы известного типа — конечно можно.

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

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

PD>Ни в C++, ни в Паскале тип нельзя представить как область памяти. Более того, в run-time его вообще не существует, если нет RTTI.
Кажется, GlebZ как раз и указывал на то, что в .NET ситуация обратная. Все типы программы очень даже существуют runtime.

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

Mab>Кажется, GlebZ как раз и указывал на то, что в .NET ситуация обратная. Все типы программы очень даже существуют runtime.

А, ну тогда сорри. При включенном RTTI в unmanaged C++ типы тоже существуют в ран-тайме. Хотя и в существенно ином виде

. А в Object Pascal есть даже переменные типа "тип", правда, как они реализованы, я не знаю.

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

О! Ну, вот они "ушки" проклюнулись!

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

Ты же сам говоришь объект! Так зачем же делать совершенно кривой дизайн обращаясь к объекту извне? Раз это объект, то и создай класс для него. В этом классе опиши все связанные с ним алгоритмы. Какие-то экземплярными методами, каки-то статическими. А уж в своей функции создай объект этого класса и используй его функцинальность. Тода твой код будет не только распеделен в пространстве, но еще и логичен. И естествнно не понадобится создавать вложенных классов.

PD>Все это интересно в данной функции. За пределами этой функции такая структура никому не нужна, да и вообще желательно, чтобы о ней никто не знал, потому как дело это сугубо внутреннее для этой функции. А получается, что сделать такое невозможно.

MF>>Так что это ограничение на самом деле тебе самому и на пользу.

PD>Не похоже...

А мне тоже кажется, что на пользу.

... << RSDN@Home 1.2.0 alpha rev. 618>>

Здравствуйте, 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 типов пока не прозвучало. Только рассказы про то, что структуры это то же самое, что переменные. Кстати, у нас за такие песни можно было на пересдачу уйти.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, 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 я знаю всё. Но это никак не делает типы и экземпляры эквивалентными.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

.

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

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

Привет!

Я правильно понимаю, что в C# нельзя описать структуру внутри функции, чтобы она только в ней и была видна

class A
{
void f()
{
struct MyStruct{
int m,n;
};
}
};

Компилятор такое не пропускает. В C++ такое допустимо.

Если да — как лучше скалькировать это с С++ на С# ? Вариант выноса стуктуры на уровень класса не годится — в функции g на С++ может быть описана другая стуктура с тем же именем.

26.09.05 21:49: Перенесено модератором из '.NET' — TK

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

PD>Я правильно понимаю, что в C# нельзя описать структуру внутри функции, чтобы она только в ней и была видна

Да. (И слава богу)

PD>Если да — как лучше скалькировать это с С++ на С# ? Вариант выноса стуктуры на уровень класса не годится — в функции g на С++ может быть описана другая стуктура с тем же именем.

Ну и что? Заведи класс _serviced или еще какой и туда засунь эту структуру.

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

A>Ну и что? Заведи класс _serviced или еще какой и туда засунь эту структуру.

Не понял. Что изменится в плане видимости, если я структуру засуну в класс ?
Кто помешает создавать экземпляры этого класса где бы то ни было ? А я хочу только в данной функции

Вот пример на C++

class MyClass
{
void f(void)
{
struct A {
int x,y;
};
// any code can use this type A (2 int fields)
}
void g(void)
{
struct A {
float a,b,c;
};
// any code can use this type A (3 float fields)
}
void h()
{
// no A declaration so type A can't be used
}
};

// no A declaration so type A can't be used

1.В функции f есть тип A — struct из 2 int. За пределами функции f он не существует.
2.В функции g есть тип A — struct из 3 float. За пределами функции g он не существует.
3.За пределами f и g никакого типа А вообще не имеется. Нельзя использовать тип A ни в других функциях класса MyClass, ни за пределами класса MyClass

Если не сложно, перепиши на C#, соблюдая требования 1-3.

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

PD>Я бы все же просил придерживаться политкорректности. Такие типы видимости существуют в Паскале, С/C++, из чего не следует, что эти языки являются параноидальными.
О, ну прошу прощения, забыл добавить ИМХО. Так вот ИМХО это и есть чистой воды паранойя. Ибо такая возможность решает несуществующую проблему. Объявление типа в виде приватного члена объемлющего класса ничем не хуже.

Объявление типа в виде приватного члена объемлющего класса ничем не хуже.
--------------
Только если таких типов штук 10 и каждый из них используется только в отдельно взятой функции, уже не будет казаться таким параноидальным.

-----
Нулевое оформления постов благодаря Opere.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

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

PD>>Я бы все же просил придерживаться политкорректности. Такие типы видимости существуют в Паскале, С/C++, из чего не следует, что эти языки являются параноидальными.
Mab>О, ну прошу прощения, забыл добавить ИМХО. Так вот ИМХО это и есть чистой воды паранойя.

Вытащил с одного сайта определение паранойи.

Паранойя, психическое нарушение, характеризующееся подозрительностью и хорошо обоснованной системой сверхценных идей, приобретающих при чрезмерной выраженности характер бреда

Не совсем понятно, при чем здесь подозрительность, а тем более сверхценные идеи

>Ибо такая возможность решает несуществующую проблему. Объявление типа в виде приватного члена объемлющего класса ничем не хуже.

А вот это опросил бы подробнее прокомментировать. Насколько я понимаю, такое объявление позволит мне создавать экземпляры этого объекта где бы то ни было внутри класса, так ?

Предположим, что класс огромный по размеру кода (я сказал "предположим", это не надо сейчас обсуждать с точки зрения хорошего стиля программирования), а поэтому его разработка поручена нескольким человекам. Им по ходу работы нужно создавать структуры (пусть даже не классы!), чтобы просто не иметь сотен переменных. Значит, им придется согласовывать друг с другом имена этих структур, так ? Ведь описания этих структур надо выносить на уровень класса ?
Или я что-то не так понял ?

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

PD>А вот это опросил бы подробнее прокомментировать. Насколько я понимаю, такое объявление позволит мне создавать экземпляры этого объекта где бы то ни было внутри класса, так ?

PD>Предположим, что класс огромный по размеру кода (я сказал "предположим", это не надо сейчас обсуждать с точки зрения хорошего стиля программирования), а поэтому его разработка поручена нескольким человекам. Им по ходу работы нужно создавать структуры (пусть даже не классы!), чтобы просто не иметь сотен переменных. Значит, им придется согласовывать друг с другом имена этих структур, так ? Ведь описания этих структур надо выносить на уровень класса ?
PD>Или я что-то не так понял ?

Не забывай про метаданные.
В каком неймспейсе, например, будет находиться эта структура?
Конечно, я согласен, что афторы C# зря убрали возможность создавать временные структуры в теле функции, но ничего не поделать.
С другой стороны, это не дает тебе писать в плохом стиле, когда тело функции занимает несколько экранов и в связи с этим нефтыкаемо методом окидывания взглядом.
Так что это ограничение на самом деле тебе самому и на пользу.

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

MF>С другой стороны, это не дает тебе писать в плохом стиле, когда тело функции занимает несколько экранов и в связи с этим нефтыкаемо методом окидывания взглядом.

Не хочу я писать в плохом стиле. Я наоборот хочу в хорошем писать

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

Все это интересно в данной функции. За пределами этой функции такая структура никому не нужна, да и вообще желательно, чтобы о ней никто не знал, потому как дело это сугубо внутреннее для этой функции. А получается, что сделать такое невозможно.

MF>Так что это ограничение на самом деле тебе самому и на пользу.

Не похоже...

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

Mab>Тут вопрос философский. .NET как платформа для разработки заодно подразумевает некоторый стиль написания кода под нее. Свойство это выражено намного сильнее, чем, скажем, в C++, где одно и то же можно описать десятью различными способами, а потом еще удивляться, отчего сосед делает это 11-м. Платформа подразумевает этот стиль временами весьма навязчиво, так что написание кода не следуя ему становится довольно затруднительным.

А кстати, если можно, еще один вопрос. Не в курсе, как в managed C++ с этим дело обстоит ? В С++ это разрешается! Или в managed запретили, или все же дело не в .Net, а только в C# ?

Mab>Поэтому не стоит удивляться, отчего платформа не дает и дальше писать код в старом стиле, делая этот "огромный" класс еще более огромным. Рефакторинг поможет решить эту проблему, благо в C# инструменты для него имеются (в отличие от C++ и Pascal).

Ладно, насчет "огромного" класса возражение приму. Но остается другое возражение, я его привел в ответе MatFiz (http://www.rsdn.ru/Forum/Message.aspx?mid=1393827&only=1)

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

PD>А кстати, если можно, еще один вопрос. Не в курсе, как в managed C++ с этим дело обстоит ? В С++ это разрешается! Или в managed запретили, или все же дело не в .Net, а только в C# ?
Нет не запретили. Это эмулируется через объявление в сборке в отдельном неймспейсе структуры с compile-generated именем.

PD>Ладно, насчет "огромного" класса возражение приму. Но остается другое возражение, я его привел в ответе MatFiz (http://www.rsdn.ru/Forum/Message.aspx?mid=1393827&only=1)
Сложно посоветовать в общем случае. Периодически на работе приходится сталкиваться с тем, что алгоритм работы отдельных функций и количество требуемых им описаний типов начинает превышать допустимые лимиты (мы, в частности, пишем код для обсчета транспортных графов, где проблемы в первую очередь алгоритмические). В такой ситуации подходящим решением оказывается выделение каждого из этих алгоритмов в отдельный класс. Вообще принцип простой: как только становится ясно, что дальнейшее наращивание размера класса приводит к трудностям при сопровождении, -- значит нужно делать рефакторинг и резать класс на более мелкие.

Ну не пойму чем тебе Hastable не нравится?

class Class1
{
public Hashtable FuncA()
{
Hashtable result = new Hashtable();
result.Add( "m", 10 );
result.Add( "n", 5 );
return result;
}
public Hashtable Func2()
{
Hashtable result = new Hashtable();
result.Add( "Cost", (double)10 );
result.Add( "MySpecificData", new MySpecificObject() );
return result;
}
}

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

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

Это ответ на несколько не тот вопрос, который я там задал

Но в общем все понятно. Нет их, и все тут, а дальше можно философствовать на тему, хорошо это или плохо, до бесконечности.

Спасибо за обсуждение.

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

Кстати, к enum это тоже относится ? Нельзя описать enum в функции ?

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

Это относится ко всем типам. Они могут быть описаны лишь внутри структур, классов или пространств имен.

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

_>Ну не пойму чем тебе Hastable не нравится?

_> class Class1
_> {
_> public Hashtable FuncA()
_> {
_> Hashtable result = new Hashtable();
_> result.Add( "m", 10 );

Хорошенькое дело! В структуре список полей жестко определен, несуществующее поле употребить просто невозможно. А здесь пиши, что хочешь! И потом стуктура все же в стеке лежит, доступ к ней прямой, а тут поиск в Hashtable.

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

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

Mab>Это относится ко всем типам. Они могут быть описаны лишь внутри структур, классов или пространств имен.

Вот это уже черт знает, что такое. Получается, что внутри функции и набор констант определить нельзя!

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

GZ>Десять переменных? Можно подумать и о классе. Пуская даже private и с одной функцией.

А не все ли равно ? Проблему-то это не решает — создать экземпляр этого класса можно будет где угодно.

GZ>Как выход, могу предложить следующий алгоритм:
GZ>1. Выделить структуру в класс.
GZ>2. Структуру определить как private
GZ>3. Переназвать структуру(например имя_функции_имя_структуры)

Ну и что ? Все равно задачу ограничить область видимости телом данной функции решить не удастся. Максимум, что это даст — при написании другой функции удастся вспомнить, что эта структура для этой функции не предназначена...

GZ>Вроде бы и стиль будет достаточно хорош.

Ох, совсем не уверен. А если потом я решу, что эту же структуру (класс) неплохо бы использовать еще в одной функции, а в остальных все же не надо. Вставить ее туда в C++ — Copy-Paste, и все дела. И о том, что я Copy-Paste сделал, я тут же и забыл — они абсолютно независимы. А здесь мне ее переименовать в
имя_функции1_имя_функции2_имя_структуры ?

. А если потом в этой другой функции я ее малость изменить захочу ?

GZ>А вообще, говорить что можно перевести с языка на язык без рефакторинга, нельзя. Это, конечно, не Лисп, но идеалогия языков различается.

Идеология — не согласен. C++,Object Pascal, Java, C# — языки в общем одной идеологии. Хотя, скажем, паскалевские вложенные функции могут доставить немало головной боли при переводе на С++.

Вот Лисп или Пролог — совсем другая идеология. Но это уже для "Священных войн"

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

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

GZ>>Десять переменных? Можно подумать и о классе. Пуская даже private и с одной функцией.

PD>А не все ли равно ? Проблему-то это не решает — создать экземпляр этого класса можно будет где угодно.

GZ>>Как выход, могу предложить следующий алгоритм:
GZ>>1. Выделить структуру в класс.
GZ>>2. Структуру определить как private
GZ>>3. Переназвать структуру(например имя_функции_имя_структуры)

PD>Ну и что ? Все равно задачу ограничить область видимости телом данной функции решить не удастся. Максимум, что это даст — при написании другой функции удастся вспомнить, что эта структура для этой функции не предназначена...
Я предложил это сделать один в один.

GZ>>Вроде бы и стиль будет достаточно хорош.

PD>Ох, совсем не уверен. А если потом я решу, что эту же структуру (класс) неплохо бы использовать еще в одной функции, а в остальных все же не надо. Вставить ее туда в C++ — Copy-Paste, и все дела. И о том, что я Copy-Paste сделал, я тут же и забыл — они абсолютно независимы. А здесь мне ее переименовать в
PD>имя_функции1_имя_функции2_имя_структуры ?

. А если потом в этой другой функции я ее малость изменить захочу ?

Поколение Copy-Paste. Ты случаем на структурных языках не писал(или VB)

Я сразу тебе говорю, что так НЕ БЫВАЕТ. Если структуры имеют даже несколько одинаковых полей, то это уже повторение кода. Так как за полями всегда стоит функциональность. Это прямой путь к рефакторингу. Если хочешь, выложи этот класс, и мы посмотрим что с ним можно сделать.

GZ>>А вообще, говорить что можно перевести с языка на язык без рефакторинга, нельзя. Это, конечно, не Лисп, но идеалогия языков различается.

PD>Идеология — не согласен. C++,Object Pascal, Java, C# — языки в общем одной идеологии. Хотя, скажем, паскалевские вложенные функции могут доставить немало головной боли при переводе на С++.
Нет. Ты как раз и попал на разницу в идеологиях. В NET тип нельзя представить как область памяти. Любой тип описывается в метаданных. И различий значительно больше. Множественное наследование, reflection, сборки(можно сказать компоненты), шаблоны и генерики(которых де юре еще не существует), object vs void*(которым и в С++ 1000 раз подумаешь чем воспользуешься и все это приходится обходить), интерфейсы. И этот список можно долго продолжать.

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

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

GZ>Поколение Copy-Paste. Ты случаем на структурных языках не писал(или VB)

Естественно. И даже на неструктурных тоже (Фортран 4)

>Я сразу тебе говорю, что так НЕ БЫВАЕТ. Если структуры имеют даже несколько одинаковых полей, то это уже повторение кода.

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

>Так как за полями всегда стоит функциональность. Это прямой путь к рефакторингу. Если хочешь, выложи этот класс, и мы посмотрим что с ним можно сделать.

Да ничего не надо. Просто вопрос возник.

GZ>Нет. Ты как раз и попал на разницу в идеологиях. В NET тип нельзя представить как область памяти.

Ни в C++, ни в Паскале тип нельзя представить как область памяти. Более того, в run-time его вообще не существует, если нет RTTI.

>Любой тип описывается в метаданных. И различий значительно больше. Множественное наследование, reflection, сборки(можно сказать компоненты), шаблоны и генерики(которых де юре еще не существует), object vs void*(которым и в С++ 1000 раз подумаешь чем воспользуешься и все это приходится обходить), интерфейсы. И этот список можно долго продолжать.

Это тоже все в "Священные войны"

. Если коротко — отличия того же порядка, как отличия С++ от Object Pascal. А оба они от Лиспа отличаются на 2 порядка.

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

ALV>Только если таких типов штук 10 и каждый из них используется только в отдельно взятой функции, уже не будет казаться таким параноидальным.

Вопрос дизайна. При нормальном дизайне вообще не должно возникать потребности в тысячах скрытых классов.

Ну, а если очень хочется, то функцию можно объявлять внутри того самого вложенного класса.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

PD>Предположим, что класс огромный по размеру кода (я сказал "предположим", это не надо сейчас обсуждать с точки зрения хорошего стиля программирования), а поэтому его разработка поручена нескольким человекам. Им по ходу работы нужно создавать структуры (пусть даже не классы!), чтобы просто не иметь сотен переменных.

Для этого лучше воспользоваться partial-классами. Да и если уж работа ведется несколькими человеками, то просто необходимо выносить классы в отдельные файлы. Так что спокойно создавайте отдельные классы и используйте их. А для отделения используйте пространства имен.

PD> Значит, им придется согласовывать друг с другом имена этих структур, так ? Ведь описания этих структур надо выносить на уровень класса ?
PD>Или я что-то не так понял ?

Да. Ты не понял, что каждый инструмент требует своего подхода/стиля. Переносить 1 в 1 опыт Плюсов на Шарп занятие неблагодарное.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

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

VD>О! Ну, вот они "ушки" проклюнулись!

Не понял. Объясни, что имел в виду.

VD>Ты же сам говоришь объект!

Я сказал специально "объект в общечеловеческом смысле". А не объект .Net.

>Так зачем же делать совершенно кривой дизайн обращаясь к объекту извне? Раз это объект, то и создай класс для него. В этом классе опиши все связанные с ним алгоритмы. Какие-то экземплярными методами, каки-то статическими. А уж в своей функции создай объект этого класса и используй его функцинальность. Тода твой код будет не только распеделен в пространстве, но еще и логичен. И естествнно не понадобится создавать вложенных классов.

Все это в теории совершенно верно. А на практике иногда хочется банально объединить две-три переменные в банальную структуру, просто потому, что переменные эти взаимосвязаны и имеет смыл их рассматривать как единое целое. Навешивать сюда какие-то функции незачем, все довольно просто , и мне просто нужен старый добрый struct языка С (не С++!), чтобы можно было нескольких переменных не иметь, а вместо них одну. Да и копировать проще — начни отдельные переменные копировать — чего доброго , забудешь какую-нибудь.

Вот тебе вполне искусственный пример. Нужна мне материальная точка.

struct MP
{
int x,y,z;
float weight;
};

и все, пламенный привет. Никакие методы мне не нужны. Либо 4 переменные, либо одна MP. И не хочу я, чтобы эта MP была видна где-то еще. Потому как вообще-то в проекте все координаты вещественными должны быть (такие требования), а вот здесь мне нужны 3 целые координаты и вещественный вес.

Если я структур заводить не буду, а просто опишу 4 переменные

int x1,y1,z1;
float weight1;

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

Ну а потом я решу, что 2 такие переменные мне нужны

int x2,y2,z2;
float weight2;

и надо скопировать

x2=x1; y2= y1l z2 = z1; // а про weight забыл

А я бы предпочел упростить все это

MP mp1, mp2;

mp2 = mp1;

И что же здесь криминального ? И обязательно ли здесь огород (класс т.е. городить) ?

Кстати, в managed C++ это разрешено. Так что дело не в идеологии .Net, а просто авторы C# так сделали. Вот в Алголе были вложенные функции, Вирт эту идею подхватил, и они есть в Паскале и Модуле. А в других языках их нет. И причины здесь не столько идейные, сколько... черт знает какие.

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

VD>Для этого лучше воспользоваться partial-классами. Да и если уж работа ведется несколькими человеками, то просто необходимо выносить классы в отдельные файлы.

Угу. При том. что по смыслу задачи это один объект, надо искусственно его разбить на ряд классов просто потому, что один человек за отведенное время справиться с написанием кода не в состоянии. В этих классах придется определить как свойства всякие внутренние поля (чтобы классы друг с другом могли взаимодействовать) при том, что по смыслу задачи эти поля super private

и к ним вообще никто постронний доступ иметь не должен. Нет, мне эта идея не нравится.

VD>Да. Ты не понял, что каждый инструмент требует своего подхода/стиля. Переносить 1 в 1 опыт Плюсов на Шарп занятие неблагодарное.

Ясно. Приму к сведению

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

...Надо признать, что авторы C# были прозорливы. Еще не один год их огнаричения и решения будут разбирать в филосовкких влэймах.

Ну, а если в лом, то путь С++ не закры.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

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

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

VD>>О! Ну, вот они "ушки" проклюнулись!

PD>Не понял. Объясни, что имел в виду.

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

А если тебя вдруг тянет банально объеденить две переменные, то нужно останавливаться и возвращаться к дизайну системы. Переменные ведь не просто так связаны. Скорее всего они являются частью состояние некой более абстракной сущности.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

PD>Кстати, к enum это тоже относится ? Нельзя описать enum в функции ?

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

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

PD>Вот это уже черт знает, что такое. Получается, что внутри функции и набор констант определить нельзя!

Константы можно. Только в дотнете и Шарпе перечисления не являются константами. Перечисление это одтельный тип. Ты даже обращаться к членам перечисления не можешь без квалификации типом:

enum A
{
    A,
    B,
}

class Test
{
    public Test()
    {
        int const1 = B; // так нельзя
        int const2 = A.B; // и так нельзя
        A const3 = A.B; // а так можно
        int const4 = (int)A.B; // а так можно
    }
}

В общем, в Шарпе перечисление это именно тип, а не способ описать целочисленные константы. И это очень веро, так как получается меньше ошибок (веренее большее их число отлавливается компилятором).
Если нужны именно константы, то нефига извращаться. Зводи именно константы.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

_>2 Автор
_>Используй C#3

Там есть неименованные структуры

Нет там никаких анонимных структур. Пока что анонимные типы выраждаются в классы. А что будет в релизе вообще не ясно.

_>Возвращай Hashtable, если возможно

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

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

S>Ты не мог бы пояснить подробнее причины прятать структуру от остальных?

А ты не мог бы объяснить причины прятать переменные от других ? Вопрос, естественно, риторический, ответ на него очевиден. А ведь структуры в Шарпе — тоже в некотором смысле переменные, почему же для переменных допустима область видимости — функция или даже блок, а для типов — нет ?

Я вижу две проблемы:
S>1. Есть риск конфликта имен.

Это тоже, но не главное.

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

Sinclair, ну зачем же так ? Я MP привел просто для того, чтобы не писать лишнего в письме. Естественно, я так писать не буду. Но отмечу, что какие имена не придумывай, все равно "спид, ребята, неизбежен". С некоторой долей вероятности. Чтобы его не было, придется в качестве имен классов GUID использовать

>Уже при декларации приватного типа в пределах класса мы сводим риск конфликта имен к минимуму.

Но не к нулю.

S>2. Есть риск того, что кто-то использует структуру без твоего ведома.

Это не существенно.

S>А зачем доходить до абсурда? Что, здравый смысл уехал в отпуск? Если у тебя есть группа переменных, изменяющихся согласованно, то имеет великий смысл выделить их в некую структуру. Хотя бы потому, чтобы читателю было понятна эта группировка. Отличия структов от классов минимальны в плюсах, и, хотя в дотнете они заметнее, обсуждать их смысла не имеет.

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

. Я не против структур. Я хочу локальные описания стуктур в функциях, как в C++, Delphi.

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

. Почему же тип может существовать только на уровне класса — не понимаю.

Вот пример. Пусть есть класс

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

Работает он с неким устройством, умеет писать и читать, больше ничего. Устройство использует 20 структур при операциях чтения (т.е. с устройства читаются пакеты 20 разных видов) и 30 структур при операциях записи. Пакеты, подчеркиваю. Им глубокой логики не надо, из них класс с десятком функций делать не стоит, их просто сформировать надо и отослать. Из этих 20 и 30 структур лишь 5 являются общими для чтения и записи. Эти 5 имеет, конечно, смысл, вынести на уровень класса. А остальные 15 и 25 соответственно ИМХО лучше поместить внутрь Read или Write соответственно. Кстати, только Read или Write знает, как этот пакет правильно парсить/формировать.
Разбивать этот класс на 2 класса , конечно, можно, но есть ли в этом смысл ? Ведь кроме этих структур, класс DeviceManager имеет еще 20 полей, которые используются в обеих функциях и непосредственно с в/в не связаны . Разбить на 2 класса — придется для этих полей свойства писать, чтобы доступ к ним был. Да и вообще это не логично — класс-то логически один.

S>В общем, то, что запрет на декларирование типов внутри метода заметно мешает работе, указывает на тяжелые проблемы с проектированием и менеждментом. Очень тяжелые проблемы. Их, скорее всего, невозможно разрешить синтаксическими способами.

Позволю себе не согласиться. В С++ это есть и никому не мешает. В Object Pascal тоже. Утверждать такое на основании лишь того, что в Шарпе MS это не реализовала я бы не стал.

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

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

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

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

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

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

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

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

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

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

.

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

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

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

S>

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

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

Скажу больше. Это тоже плохой С-шный стиль (именно С-шный, а не С++-ный). Переменные лучше объявлять при их первом использовании. Тогда и места меньше нуно, и яснее их назначение, и вероятность оставить ее неинициализированной существенно уменьшается (хтя это уже в C# сделать крайне сложно вообще).

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

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

Полностью согласен с предыдущим аратором.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

PD>

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

Нет. Те используют языки ориентированные на процедурное/функциональное программирование. Ты же выбрал язык который просто не удобен для не ОО-кодирования.

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

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

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

Там и функции глобальные описать можно. Проблема только в том, что их никто не поймет. А еще там влет можно пройтись по памяти или вызвать переполнение буфера.

При разработке C# ставилась цель создать язык общего назначения который будет в первую очередь безопастным, во вторую простым, в третью объектно ориентированным. Задачи сдирания всего что есть в С++ не входило. По этому получился язык только синтаксически похожий на С++. Применять его унжно совсем по другому. Но если научиться его применять как надо, то очень вероятно, что С++ начнет со временем вызвать тошному. Я тому живой пример.

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

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

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

.

Это то объяснение которое тебе хочется видеть. Тут вот рядом был флэймец с ВБ-шниками которые в упор отказывались понимать (а точнее, как ты, принимать) то что в C# нет индексированных свойств и дефолтных свойств. Аргументация была в точности противоположенная твоей. Мол "в MSIL-е же индексированные свойства есть, и индексатор C#-а превращается при компиляции в нег, значит индексированные свойства есть в C#". Пролодление было уже в твоем духе (только еще и в хамской манере). "...он явно он их не дает сделать потому что C# фуфло!". Вот така логика.

PD>Ну а правильно это или нет — будущее покажет.

Да уже показало. Для всех кто покончил с настальгией по тараканам С++ подобные штуки проблемой не являются. Даже ярые апологеты С++ вроде ПК находят куда более тонкие (и надо признать порой не безосновательные) претензии в C#.

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

S>Видишь ли, в шарп не стали вносить все, что "не помешает".

Золотые слова. И вообще законченная вещь — это ни когда нечего больше добавить, а когда нечего больше отнять (с) кто-то мудрый.

... << RSDN@Home 1.2.0 alpha rev. 618>>

.

Я тоже писал на C++/Pascal, и Синклер писал. Но почему-то желания получить локальные классы не имеем.

Я бы еще согласился бы если поступило предложение ввести некие дополниельные оласти видимости в которых можно было бы собирать нечто относящееся к реализации некоторого метода. Ну, нечто вроде вложенных функций в Pascal-е, но без функций. Ведь, как правильно заметил Синклер, функция на 500 строк это жуть и мрак.

Кстати, почему тебя не напрягает отсуствие в С++ возможнсоти создать вложенную функцию? Ведь в Паскале это есть, и никого это не напрягает?

... << RSDN@Home 1.2.0 alpha rev. 618>>

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

PD>Все это интересно в данной функции. За пределами этой функции такая структура никому не нужна, да и вообще желательно, чтобы о ней никто не знал, потому как дело это сугубо внутреннее для этой функции. А получается, что сделать такое невозможно.

Специальная структура только для одной функции? Сдается мне, что функционал этой функции перегружен. А если еще будет такая внутренняя структура, то эту функцию отрефакторить как следует будет нельзя.

... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>

Sinclair,

> Ты не мог бы пояснить подробнее причины прятать структуру от остальных? Я вижу две проблемы:
> 1. Есть риск конфликта имен.

И это тоже. Особенно актуально в больших проектах с долгим временем жизни, где разработка ведется в параллельных ветках SCM и т.п.

> 2. Есть риск того, что кто-то использует структуру без твоего ведома.
> Вот этого аргумента я вообще понять не могу. Ну, использует, и что? Какой вред-то от этого произойдет?

Например, может прятаться конкретный класс при реализации одного из вариантов factory method. В случае, если конкретный класс определяется внутри порождающей функции, мы видим, что никто точно не лезет к деталям реализации конкретного класса, т.к. вынужден работать через базовый интерфейс. В случае, если конкретный класс определен "вовне", нужно так или иначе дополнительно заботиться о локализации доступа к нему. Впрочем, наверное, т.к. в C# нет "свободных" функций, это не так актуально, т.к. там вместо функции в обсуждаемом варианте:

auto_ptr<AbstractProduct> create_product()
{
   class ConcreteProduct : public AbstractProduct
   {
     . . .
   };

   return auto_ptr<AbstractProduct>( new ConcreteProduct );
}

наверное, сразу будет сделан специальный класс:

public class ProductFactory
{
   private class ConcreteProduct : AbstractProduct
   {
     . . .
   }

   public static AbstractProduct create_product()
   {
     return new ConcreteProduct();
   }
}

Posted via RSDN NNTP Server 2.0 beta

_>2 Автор
_>Используй C#3 Там есть неименованные структуры
Нет там никаких анонимных структур. Пока что анонимные типы выраждаются в классы.

Мда, действительно.

А что будет в релизе вообще не ясно.

Само собой

_>Возвращай Hashtable, если возможно

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

Ну если человеку очень хочется сгруппировать несколько переменных. Почему бы их не сгруппировать в Hashtable

А вообще, конечно верно, что:

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

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

В С++ такое допустимо — вот только толку от этого мало, поскольку такая структурка не может быть параметром шаблона

... << RSDN@Home 1.1.4 stable rev. 510>>

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

L> В С++ такое допустимо — вот только толку от этого мало, поскольку такая структурка не может быть параметром шаблона

Это поправимо в следующей версии спецификации. Жаль только, что темп работы комитетчиков столь нетороплив...

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это поправимо в следующей версии спецификации. Жаль только, что темп работы комитетчиков столь нетороплив...

А в C++/CLI?

... << RSDN@Home 1.2.0 alpha rev. 617>>

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

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

MF>>С другой стороны, это не дает тебе писать в плохом стиле, когда тело функции занимает несколько экранов и в связи с этим нефтыкаемо методом окидывания взглядом.

PD>Не хочу я писать в плохом стиле. Я наоборот хочу в хорошем писать

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

ПК>>Это поправимо в следующей версии спецификации. Жаль только, что темп работы комитетчиков столь нетороплив...

AVK>А в C++/CLI?

Только в C++/CLI это делать будет странно: ничего специфического для CLI в этой возможности нет. Данная возможность с разработчиками VC++ еще не обсуждалась, но я планирую сделать это в ближайшее время.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Только в C++/CLI это делать будет странно

Ничего странного. С++/CLI, в отличие от С++, на комитет не подвязан и менять его значительно проще.

... << RSDN@Home 1.2.0 alpha rev. 617>>

AndrewVK,

> ПК> Только в C++/CLI это делать будет странно
>
> Ничего странного. С++/CLI, в отличие от С++, на комитет не подвязан и менять его значительно проще.

VC++ тоже к комитету не подвязан, и менять его ничуть не сложнее, чем C++/CLI. Точнее даже, ровно так же менять, даже в одном и том же месте, и даже одними и теми же разработчиками

Posted via RSDN NNTP Server 2.0 beta

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

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

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

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

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

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

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

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

PD>Успехов!

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

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

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

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

Тебе бы Рихтера не мешало бы почитать на предмет типов .NET , а по поводу кода и некоторых советов не обязательно на 100% верных С. Макконнел "Совершенный код" ....

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 618>>

От:	Sinclair	https://github.com/evilguest/
Дата:	23.09.05 09:19
Оценка:	29 (3) +2

От:	Sinclair	https://github.com/evilguest/
Дата:	22.09.05 06:46
Оценка:	17 (2) +4

	От:	Pavel Dvorkin
	Дата:	23.09.05 09:42
	Оценка:	6 (1) -4

От:	Sinclair	https://github.com/evilguest/
Дата:	23.09.05 11:13
Оценка:	+2

От:	Mab	http://shade.msu.ru/~mab
Дата:	21.09.05 06:59
Оценка:	1 (1) -3

От:	VladD2	www.nemerle.org
Дата:	21.09.05 11:36
Оценка:	+1

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	23.09.05 11:37
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	24.09.05 11:15
Оценка:

	От:	Павел Кузнецов
	Дата:	25.09.05 06:16
	Оценка: