Return из метода, 3 варианта. Использовать int или byte?

К примеру, нам нужно возвращать из метода 3 варианта, bool нам не подходит, так как больше 2-ух, стоит ли использовать byte вместо int для какой-либо пользы(оптимизация, экономия озу и т.д). Ибо byte 0-255, а int -2,147,483,648 - 2,147,483,647

0

Defences,
Перечисление подойдет?

1

Даценд, спасибо, все же есть разница между byte или int? enum это лишний код, ведь проще при написании метода сразу объявить возвращяемые данные.

P.s нужно возвращать из ментода Да/Нет/Не знаю, bool охватывает только два Да/Нет.
Значит будем использовать int
0 - Да
1 - Нет
2 - Не знаю

Меня интересует, а не лучше будет создавать не int ради 3 вариантов возврата 0,1,2 а short или вообще byte?

0

Nullable bool?

0

Сообщение от Defences bool охватывает только два Да/Нет.

Есть nullable тип bool? (? - часть названия типа). Там три значения: true, false, null

Сообщение от Defences не лучше будет создавать не int ради 3 вариантов возврата 0,1,2 а short или вообще byte?

Лучше int.

1

Даценд, дико извиняюсь, но все ж таки, чем лучше то?

0

Даценд, мне тоже интересно, ибо если дело обстоит как и с переменными, то для создания

Потратится больше ОЗУ и ресурсов, чем для
P.s спасибо за bool? с ним можно 3 варианта обрабатывать, а если 4 и более, то все же не понятно byte, short или int?

0

Сообщение от Defences Потратится больше ОЗУ и ресурсов

Любите на спичках экономить? К тому же, ответ из метода ВСЕГДА вернётся в регистре процессора, а он 32\64 битный (зависит от архитектуры винды). Так что экономии ОЗУ (как и траты) - нуль.

Правильной практикой является использование перечислений (Enum), как и было выше посоветовано. "Лишенего кода" всего несколько строк, в замен же вы получаете повышенную читабельность кода и самодокументированность сигнатуры метода. Т.е. гляда на метод static MyEnum GetVariant(int x) вы уже точно можете сказать, что именно он вернёт, чего не скажешь про вариант static int GetVariant(int x). Если вы считаете, что это лишнее и вы будете помнить что может вернуть метод, то я вас расстрою: это "помнить" улетучивается очень быстро, а сторонний программист вообще не в курсе изначально.

К тому же, если вы любите экономить там, где это невозможно, то имейте в виду, что Enum - тип значащий (по умолчанию Int32) и его тип можно явно задавать:

1

Usaga, а если таких методов много, где возвращается 3 или более и они похожи, можно ли сделать вспомогательный static class где будут хранится enum?

Определить состояний 10 и оттуда черпать для всех методов, где это требуется, какой-то метод возвращает только 4, другой 8 и т.д

0

Defences, зачем перечисления прятать в статичный класс? Пускай просто висят в пространстве имён и будут доступны всем. Или я не правильно понял ваш вопрос?

1

Сообщение от Defences Определить состояний 10 и оттуда черпать для всех методов, где это требуется, какой-то метод возвращает только 4, другой 8 и т.д

Похоже, вы не понимаете зачем нужен enum. Давайте я объясню почему все вышеперечисленные варианты не годятся (кроме enum) и почему:

1) Самое главное это не синтаксис и не объем памяти. Главное - это семантика программы, ее смысл и понятность. ООП придумано не для машины, а для человека. Компьютер одинаково понимает и ассемблер и C# - ему все равно. А вот человеку - не все равно. Поэтому ваша программа в первую очередь должна быть понятной человеку.

2) Теперь посмотрим на варианты возврата byte и int (пока не будем трогать техническую сторону). Эти варианты не годятся потому что они не отражают семантику возвращаемого значения. Вы сами пишите:
То есть вы возвращаете не просто числа, вы возвращаете коды которые имеют семантику. Но как внешняя программа поймет смысл этих кодов, если вы вернете int? Никак. Значит такой вариант не годится. Кроме того, эти числа могут принимать больше значений чем 3, соответственно возрастает вероятность неправильной интерпретации.

3) Далее, вариант bool? также плох. Да, он может принимать три значения, но смысл этих значений - совершенно другой. Здесь будет нецелевое использование значений. Этот вариант еще хуже чем int потому что у чисел нет особого значения, а у bool? - есть вполне конкретные значения - true, false и null. И они не совпадают с теми, которые нужны вам. То есть вы не просто не помогаете внешнему читателю кода, а еще и запутываете его.
Кроме того, здесь проблема еще и в том, что если вы в будущем захотите возвращать не три а более значений, то bool? станет точно непригодным для использования.

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

Я так понимаю, вас смущает то, что для этого нужно создавать отдельный класс(enum), и что это лишняя работа? Это не так. Представьте себе ситуацию - вы разработали программу и уволились. А вместо вас пришел новый программист. Откуда программист узнает что означают все эти int, byte или bool? Ниоткуда. Вам придется ему писать тех документацию - типа "0 - Да, 1 - Нет, 2 - Не знаю". Но если это все равно придется писать, то не легче ли это сразу написать в коде - в виде enum? Ваш код должен быть понятен и очевиден сам по себе, должен быть самодокументированным. Что бы любой человек, взглянувший на него легко понял, что код делает, какие значения возвращает и т.д. Именно для этого и необходимо enum.

Теперь что касается технической стороны вопроса.
Как уже писали - при возврате значений по любому возвращается машинное слово (32 или 64 бита) независимо от типа (хоть int, хоть byte). Поэтому здесь нет экономии. Существенная разница между byte и int может быть только при хранении этих величин и в больших масштабах. То есть если бы у вас был массив на сотни миллионов значений, тогда было бы уместным думать о том, хранить это в byte или int - разница была бы в 4 раза. Но это не ваш случай.
Вариант с bool? еще хуже, потому что этот тип является ссылочным типом-оберткой, и он занимает в памяти не 1 байт и не 4 байта а намного больше (не менее 16 байт). Но опять же это было бы важно только при хранении больших объемов данных. Для простого возврата из метода это не имеет особого значения.

Поэтому вам нужно сделать enum, перечислить в нем варианты значений, четко передавая их смысл. Если вы эти значения собираетесь хранить в больших объемах - enum можно унаследовать от byte для экономии памяти.

Сообщение от Defences Определить состояний 10 и оттуда черпать для всех методов, где это требуется, какой-то метод возвращает только 4, другой 8 и т.д

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

6

Defences, А что, если не секрет, вы пишете? что за методы? может вы изначально делаете не так.

Плевать на ООП, как предлагаете вы, нужно только тогда, когда в профилировщике вы нашли узкое место в плане производительности или памяти, которое нужно оптимизировать.

0