Язык программирования Си#: критическая оценка

Сергей Свердлов


ОГЛАВЛЕНИЕ
Избыточность
Побочный эффект
Тяжеловесность
Читать или писать?
Перспективы Си#

Избыточность

Некоторые средства языка Си# являются избыточными — в том смысле, что не добавляют к языку никаких функциональных возможностей, а лишь позволяют в иной форме записать то, что и так может быть выражено достаточно просто.

К числу таких средств относятся свойства (properties) и индексаторы (indexers).

Свойства маскируют обращение к процедуре (методу) под обращение к переменной (полю).

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

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

Пусть строковое (типа string) свойство Title экранных объектов класса Element задает надпись-заголовок таких объектов. Объявление этого свойства может выглядеть так: public class Element {

string title; // Это поле

public string Title { // А это - свойство

get { return title;}

set {

title = value;

Repaint(); // Перерисовать

}

}

// Далее определяются другие поля и методы

...

}

Сама надпись хранится в поле title, а свойство Title организует доступ к нему c помощью подпрограмм get (получить) и set (установить). Если e — переменная, обозначающая объект класса Element, то для изменения надписи и перерисовки объекта на экране достаточно записать: e.Title = “Привет”;

Такое присваивание приводит к выполнению подпрограммы set. А, например, при выполнении оператора, добавляющего к заголовку восклицательный знак: e.Title += “!”; неявно вызываются и get, и set.

Между тем доступ к заголовку экранного элемента может быть оформлен и без использования свойств: public class Element {

string title;

public string getTitle() {

return title;

}

public void setTitle( string value ) {

title = value;

Repaint(); // Перерисовать

}

// Далее определЯютсЯ другие полЯ и методы

...

}

В этом случае вместо e.Title = “Привет”; нужно записать e.setTitle(“Привет”); а взамен e.Title += “!”; необходимо использовать e.setTitle(e.getTitle()+“!”);

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

От него не скрывается тот факт, что изменение заголовка выполняется подпрограммой, которая кроме присваивания значения может выполнить и другие действия. В первом же случае по тексту программы невозможно (без обращения к описанию класса Element) отличить использование свойств от использования обычных полей.

Программирование в среде визуальных систем, подобных Delphi, откуда в язык Си# перекочевали свойства, можно разделить на несколько уровней. Первый — разработка прикладных программ. В этом случае программист, создавая программу с графическим интерфейсом пользователя, как правило, оперирует лишь готовыми компонентами с уже запрограммированными свойствами.

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

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

Второй уровень — разработка визуальных компонентов. Здесь на программиста возлагается полная ответственность за корректность создаваемой системы классов.

Наконец, следует рассмотреть использование языка, оснащенного свойствами, вне контекста визуальной среды*.

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

Весьма неоднозначный смысл имеет конструкция Си#, называемая индексатором. Индексаторы — это элементы классов (а также интерфейсов и структур), позволяющие обращаться к объектам как к массивам (указанием индекса в квадратных скобках). Реализуется такой доступ неявно вызываемыми подпрограммами get и set.

Например, обращение к отдельным битам 32-разрядного целого значения (bits) можно замаскировать под обращение к логическому массиву. Для этого создается такое описание (в данном случае структуры): public struct BitSet {

int bits; // Поле целого типа

public bool this[int i] { // Индексатор

get{return 0<=i && i<32? (bits & 1<

set {

if(i<0 || i>31) return;

if(value) bits |= 1<

}

}

}

Теперь использование переменной типа BitSet может выглядеть, например, так:

BitSet b = new BitSet(); // Описание переменной

...

// Все биты устанавливаются в единичное значение

for (int i=0; i<32; i++ )

b[i] = true;

...

if(b[i]) ( // Проверка i-го бита

...

В описании типа BitSet использовано много специфических обозначений: && — условное “И”; & — поразрядное логическое “И”; << — сдвиг влево; != — не равно; ... ? ... : ... — условная операция, если логическое выражение перед “?” истинно, то результат операции вычисляется по выражению, записанному перед двоеточием, если нет — по выражению, записанному после двоеточия; || — поразрядное логическое “ИЛИ”; |= — присваивание с поразрядным “ИЛИ” (обратите внимание на схожесть с !=); &= — присваивание с поразрядным “И”; ~ — поразрядное “НЕ”. Идентификатор value представляет значение, переданное подпрограмме set.

Конечно, те же функциональные возможности могут быть обеспечены и без индексаторов: public struct BitSet {

int bits;

public bool get(int i) { // Получить

return 0<=i && i<32? (bits & 1<

}

public void set(int i, bool value) { // Установить

if(i<0 || i>31) return;

if(value) bits |= 1<

}

}

Обратите внимание, что содержание подпрограмм get и set нисколько не изменилось. Только теперь это обычные методы. Для доступа к отдельным битам квадратные скобки уже не применить:

BitSet b = new BitSet(); // Описание переменной

...

// Все биты устанавливаются в единичное значение

for (int i=0; i<32; i++ )

b.set(i, true);

...

if(b.get(i)) ( // Проверка i-го бита

...

По-видимому, одной из причин появления индексаторов в Си# было желание создателей языка естественным образом оформить обращение к символам строк, которые в Си# являются объектами, но не массивами. Если s — строка (string), то только благодаря наличию в классе string индексатора i-й символ строки s можно обозначить s[i].

В языке Java, где строки — тоже объекты, для обращения к отдельному символу приходится вызывать специальный метод: s.charAt(i).

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

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

Недостатков можно назвать больше:

* усложняются язык и компилятор. С появлением свойств и индексаторов возникает много новых правил. В справочнике по Си# свойствам посвящено целых восемь страниц;

* при использовании свойств и индексаторов от программиста скрываются затраты на обработку подпрограмм доступа get и set, что провоцирует к употреблению неадекватных и неэффективных приемов.

Например, использование индексатора для доступа к элементам линейного списка по их номеру** при значительной длине списка гораздо менее эффективно, чем обращение к элементу массива, хотя выглядит так же. Применение такого индексатора для последовательного просмотра списка — и вовсе абсурд, к которому, тем не менее, вас подталкивают;

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

Приведу пример, когда простейший фрагмент, работа которого в иных обстоятельствах понималась бы абсолютно однозначно, а при использовании Си# совершенно непредсказуема:

int i, s=0;

for (i=1; i<=100; i++ ) a[i]=i;

for (i=1; i<=100; i++ ) s += a[i];

System.Console.WriteLine(s);

Ну и что тут такого? Вначале элементам “a” поочередно присваиваются значения первых ста чисел натурального ряда: 1, 2, 3, ..., 99, 100. Затем вычисляется и выводится сумма этих чисел, которая обязательно должна быть равна 5050. Но ничего подобного! Напечатанное этой программой значение может оказаться каким угодно. Например, равным 338 350, если “a” — индексируемый объект такого типа: class Array {

public int this[int i]{

get{ return i*i; } // i-е значение равно i*i

set {} // Никаких действий

}

}

* Для языка Объектный Паскаль, который используется в Delphi, такое применение не слишком актуально. Это специфический язык конкретной системы визуального программирования. Однако язык Си#, по-видимому, претендует на всеобщность, на существование не только в рамках конкретной среды.

** Именно этим примером иллюстрируется использование индексаторов в документации по Си#.

Источник: http://www.pcweek.ru/?ID=56351

Цитата(Pegas @ 21.12.2004, 12:13)

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

Ну и бредятина, честно говоря. Свойства для того и сделаны (помимо всего прочего), чтобы дать возможность программисту внести логику на присваивание значения, и на его получение - простой пример - Lazy Load. И слова о том, что это ухудшает читабельность программы, по меньшей мере, спорны.

Цитата(Pegas @ 21.12.2004, 12:13)

По-видимому, одной из причин появления индексаторов в Си# было желание создателей языка естественным образом оформить обращение к символам строк, которые в Си# являются объектами, но не массивами. Если s — строка (string), то только благодаря наличию в классе string индексатора i-й символ строки s можно обозначить s[i].

Еще один маразм. А как насчет обращения к hashtable по ключу? Человек явно не понимает, или, что более вероятно, не видит в силу закоснелости, удобных нововведений.

Цитата(Pegas @ 21.12.2004, 12:13)

Ну и что тут такого? Вначале элементам “a” поочередно присваиваются значения первых ста чисел натурального ряда: 1, 2, 3, ..., 99, 100. Затем вычисляется и выводится сумма этих чисел, которая обязательно должна быть равна 5050. Но ничего подобного! Напечатанное этой программой значение может оказаться каким угодно. Например, равным 338 350, если “a” — индексируемый объект такого типа

Приводить пример использования без объявления (до самого примера) типа переменной "a" - очень интересный подход. Может, он и программы так же пишет?

В общем, ерунда какая-то. Статья пуриста от программирования.

Заметил еще вот дату публикации - я думаю, что на такое старье тут в форуме не стоит даже ссылаться - с тех пор уже многое было сделано.

Это сообщение отредактировал(а) arilou - 21.12.2004, 12:40

Ок. Интересно было услышать мнение учатсников. Собственно для этого и постил.

Привык к полям(гетеры/сетеры) и индексному обращению из JS, для меня это привычно и удобно(индексы). Замаскированные Гетеры/сетеры действительно могут вести к неясному и не эффективному коду. Но как говорится не можешь держать ружьё - не ходи на охоту. Количество ошибок зависит от програмиста.

Цитата(Sardar @ 21.12.2004, 17:32)

Но как говорится не можешь держать ружьё - не ходи на охоту. Количество ошибок зависит от програмиста.

Хорошо сказано

Туфта полная.
Неужили это и в самом деле в журнале печаталось?
Что-то автор, похоже, не очень в программировании...

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

Я бы сказал по-другому: Плохому танцору - известно, что мешает

Цитата

Приведу пример, когда простейший фрагмент, работа которого в иных обстоятельствах понималась бы абсолютно однозначно, а при использовании Си# совершенно непредсказуема:

Становиться понятно, что человек не знаком с перегрузкой операторов

Цитата(bel_nikita @ 22.12.2004, 15:19)

Становиться понятно, что человек не знаком с перегрузкой операторов

После дельфи я от этой возможности просто тащюсь!

Я согласен с той мыслью в статье, что маскирование под свойствами вызова функций может приводить к неоднозначности в сложных проектах. Гораздо надежней всегда четко понимать, что происходит: вызывается функция или изменяется значение переменной.
Перегрузка же операторв хороша в тех случаях, для которых она изадумывалась. Например для класса вектора перегрузить операцию умножения и скалярного умножения. Перегружать же операции там где это не требуется - ИМХО, плохой стиль программирования.

Цитата(DENNN @ 22.12.2004, 16:41)

Перегружать же операции там где это не требуется - ИМХО, плохой стиль программирования.

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

Цитата(DENNN @ 22.12.2004, 16:41)

Я согласен с той мыслью в статье, что маскирование под свойствами вызова функций может приводить к неоднозначности в сложных проектах. Гораздо надежней всегда четко понимать, что происходит: вызывается функция или изменяется значение переменной.

Тоже спорно. Просто надо разумно использовать префиксы и давать нормальные названия пользовательским элементам.
Добавлено @ 14:10
Коментарии к статье почитайте:
http://www.pcweek.ru/?ID=56351&Discuss=1&M...#Message_108747

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

Цитата(Pegas @ 22.12.2004, 13:05)

Просто надо разумно использовать префиксы и давать нормальные названия пользовательским элементам.

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

Цитата(Sardar @ 22.12.2004, 18:09)

На мой взглят перегузка операторов это одна из самых больших ошибок, которые когда либо придумывали. Цитата(Pegas @ 22.12.2004, ) Просто надо разумно использовать префиксы и давать нормальные названия пользовательским элементам. Никогда не давал переменным префиксы, меня добивает когда тип переменной ты узнаешь по префиксу в имени. Считаю префискы в именах пережитком прошлого, IMXO.

ИМХО это поверхностное суждение и в корне неправильное, я бы даже сказал непрофессиональное. Весь мой опыт реального программирования (и не только мой) говорит о том что это только улучшает читабельность кода. А это в свою очередь приводит к меньшему количеству ошибок. Не обжайся пожалуйста на мои слова, докажи реальными примерами, что я не прав. А голословно оговорить что-то, все могут.

Цитата

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

Упс... Нифига. Перегрузка операторов - это супер. Разве плохо и неудобно складывать/вычитать/умножать/делить, например, объекты одной строкой?

Код

Object ob1; Object ob2; Object ob3; ob3 = ob1 + ob2; // разве это плохо?

И мне абсолютно пофиг, что там делается за этим + и =. Да и знать не надо. А если не уверен в + и =, то тогда вообще не следует пользоваться Object'ом, а изобретать свой велосипед.

Цитата(Pegas @ 22.12.2004, 14:23)

ИМХО это поверхностное суждение и в корне неправильное, я бы даже сказал непрофессиональное.

Ну моё утверждение тоже было мое ИМХО Просто у меня всегда появляется недоверие, когда вижу "простые" выражения в С++, сразу хочется раскопать, что же делается на самом деле. Это сбивает с толку, а вызовы методов выглядят ясно. По любому я рад что в Java нет этой возможности.

регресс.

Цитата(Sardar @ 22.12.2004, 19:31)

По любому я рад что в Java нет этой возможности.

будет.... в следующе версии.... не в следующей, так в последующей. Или будет что-то типа такого.

ИБО это очень удобный и правильный механизм. Его не зря в C# добавили.

Цитата(Pegas @ 22.12.2004, 07:56)

будет.... в следующе версии.... не в следующей, так в последующей. Или будет что-то типа такого.

Эту фичу пытались добавить в 1.5; дело в том что в Java сообществе любой человек может высказать свои пожелания к следующей версии, после чего решают добавлять или нет. В результате не добавили.

Лично я никакой крутизны в перегрузке операторов не вижу. Глубоко в нас сидит коечно восприятие "кульности" такой перегрузки; по крайней мере уменя оно сидит со времен 386 и Паскаля.

Так вот, каковы конкретно преимущества ?
1. Работать проще (заметьте, экономии места нет, скомпилируется все равно одинаково).

... и все.
Объясню: как часто оно надо? Скажем приложение клиент-сервер - куда совать эту перегрузку?
Или ХМЛ редактор? Ну ладно, пару мест можно найти, и то с натяжкой.
В основном это надо в приложениях, где идет работа с определенными юзером типами данных, причем специфическая - типа комплексных чисел.
Тогда да, удобнее писать

Код

c1 + c2 + c3 + c4

чем

Код

с1.add(c2.add(c3.add(c4)));

Недостатки:
1. Неясный код.
Предположим мы видим

Код

date++;

Вопрос - что сие означает? Да все что угодно. Ьожет, действительно идет приращение поля объекта. (какого тогда? - часы, минуты, секунды? года?) Нужно смотреть код и выяснять. Гораздо понятнее было бы

Код

date.addHours(1);

Набирать больше, но зато все понятно.

Тоже все, ИМХО.
Думаю, ни на Java, ни на С# никто мат библиотек писать не будет (из-за потери эффективности)
потому "против" для меня перевешивает аргументы "за".

Согласен с Domestic Cat, перегрузка операторов сбивает с толку, по крайней мере меня.

Еще один минус перегрузки операторов в C# - то что не все языки .Net ее поддерживают и в рекомендациях предлагается дублировать все перегруженные операторы обычными методами, что сводит удобность операторов на нет.

Вот меня всегда удивляло, почему программеры ругают некоторые НЕОБЯЗАТЕЛЬНЫЕ К ПРИМЕНЕНИЮ средства языка. Ну, блин, если нравится использовать переруженные операторы - используй, нет - не используй. Это личное дело каждого, зачем же ругать создателя?

Цитата(Kurt @ 4.1.2005, 14:56)

Ну, блин, если нравится использовать переруженные операторы - используй, нет - не используй. Это личное дело каждого, зачем же ругать создателя?

Тут еще надо учитывать договоренность в команде

Цитата(Kurt @ 4.1.2005, 14:56)

Это личное дело каждого, зачем же ругать создателя?

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

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

а) Насчет свойств. Свойства - вещь рульная и, несомненно, полезная. Я согласен с автором, что они иногда вводят программиста в заблуждение, однако я не согласен с тем, что он обвиняет в этом именно их. Виноваты не свойства, а соглашение о наименованиях в стиле Pascal. Именно благодаря ему нельзя разобраться, где у тебя метод, где поле, где свойство а где константа. Если бы ребята из мелкософт выбрали бы более удобное соглашение о наименованиях, например, как в Java, и/или договорились бы ставить перед свойствами знак подчеркивания, этого можно было бы избежать.
б) Насчет индексаторов. Опять таки вещь нужная. Вот только когда я столкнулся с кодом mess["first"] = "The first", я подумал о том, что лучше было бы пользоваться методом put("first", "The first") а индексаторы оставить для того, чтобы можно было обращаться с объектами, как с массивами, т.е. только через целочисленный индекс. На худой конец, можно было сделать дополнительный индексатор для объектов, но с круглыми скобками. Выражение mess("first") = "The first" меня лично не сбивает с толку. Хотя это на любителя. В конце-концов, привыкнуть не проблема.

Вот о чем автор не говорил, а стоило бы, так это об избыточности некоторых служебных слов. Например слово struct вещь явно лишняя, т.к. среда исполнения и сама может догадаться, что если в классе используются только данные примитивных типов, то его объекты лучше размещать в стеке. Так же явно избыточной является возможность перегрузки операции приведения типов. Гораздо логичнее, читабельнее и проще пользоваться методами toXXX(). Ведь никто не станет пользоваться выражением string s = (string) obj вместо string s = obj.toString().

А по большому счету, все эти дискуссии - только потеря времени. Не нравится - придумывай свой язык. Все равно трепотня ничего не изменит.

Цитата(Sun @ 4.1.2005, 08:37)

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

Совместимостью с С++ программистами?

Во чё раскопал   

А что сейчас мы об этом думаем?

ИМХО, все выше перечисленное (свойства, индексаторы, перегрузка) очень полезные вещи.
Но все нужно использовать с умом. 
А при небольшом желании можно многое извратить  



Руки оторвать такому програмисту надо.
А чтобы изменилось, если бы мы написали:

Это типа нормально?
Смысл ведь тот же   

Перегрузка:
Перегрузка должна подчинятся одним и тем же законам (исходя из назначения метода) и соответствовать названию метода.
Пользоваться ей так же нужно с умом 

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

mr.DUDA, осторожно, теме 2   года   

Не заметил.   

ivashkanet, гробокопатель !