Где находятся только для чтения / const в .NET?
У вас есть ошибка в методе onCreateView.
Это должно выглядеть так:
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
View rootView = inflater.inflate(R.layout.fragment_main, container, false);
// Inflate the layout for this fragment
GridView gridview = (GridView) rootView.findViewById(R.id.gridview);
gridview.setAdapter(new ImageListAdapter(getActivity(), eatFoodyImages));
return rootView;
}
5 ответов
Неизменяемость - это все еще область, в которой C# находится на стадии становления. Пока что C# не принял const семантику C++... что, на самом деле, я считаю хорошей вещью. Поведение const в C++ часто затрудняло разработку иерархий классов, которые работали бы так, как вам хотелось. Нередко можно было увидеть код, переполненный const_cast<>, чтобы обойти константность там, где это было нежелательно. Будем надеяться, что разработчики C# придумают более простую, но все еще выразительную альтернативу.
В настоящее время не существует функции языка, которая помечала бы параметры или объекты, передаваемые методам, как неизменяемые. Лучшее, что вы можете сделать, это передать объект, используя интерфейс (или, еще лучше, обертку), который разрешает только операции чтения.
Для некоторых стандартных коллекций в .NET можно использовать ReadOnlyCollection обертку, которая инкапсулирует любой изменяемый тип ICollection в контейнер, предназначенный только для чтения.
Создание неизменяемых типов требует планирования и знания особенностей языка. Например, ключевое слово readonly - ваш друг. Оно позволяет вам объявить члены класса или структуры неизменяемыми. К сожалению, эта неизменяемость относится только к ссылке, а не к членам объекта, на который ссылаются. Это означает, что вы можете объявить:
private readonly int[] m_Values = new int[100];
public void SomeMethod()
{
m_Values = new int[50]; // illegal, won't compile!
m_Values[10] = 42; // perfectly legal, yet undesirable
}
В приведенном выше примере ссылка на массив неизменяема, но отдельные элементы массива - нет. Это поведение, конечно, выходит за рамки массивов.
Практика, которую я нашел полезной при разработке неизменяемых типов, заключается в том, чтобы отделить поведение неизменяемых типов от собственного интерфейса, который затем реализуется классом, управляющим данными. Интерфейс раскрывает только свойства get и методы, которые гарантированно не будут изменять состояние объекта. Затем можно передавать экземпляры своего типа методам в качестве параметров этого типа интерфейса. Это слабая форма поддержки неизменяемости - поскольку вызываемый метод часто может привести ссылку к изменяемому типу. Лучшей, но более громоздкой альтернативой является создание реализации обертки, которая реализует тот же интерфейс и сохраняет ссылку на реальный экземпляр (подобно тому, как это делает ReadOnlyCollection). Это требует больше работы, но обеспечивает более надежную гарантию неизменяемости.
Выбор подхода зависит от того, насколько важны гарантии неизменяемости и сколько времени и усилий вы готовы потратить, чтобы добиться этого.
Если вам интересно почитать больше на эту тему, у Эрика Липперта есть отличный цикл статей о неизменяемости в C#.
насколько я знаю, это невозможно на простом пути. Возможно, эта статья даст вам несколько идей:
В C# нет модификатора const для параметров метода. Если вы хотите иметь что-то похожее на гарантии const, вы можете использовать неизменяемые типы в своих интерфейсах. Например, метод может принимать IEnumerable вместо изменяемого типа коллекции. Вы также можете посмотреть на ReadOnlyCollection.
Проблема в том, что корректность констант, используемых в C / C ++, обеспечивается только компилятором. И кстати обошел без особого труда. CLR фактически обеспечивает безопасность типов в управляемом коде, а не в компиляторе. Обязательно, потому что платформа .NET поддерживает множество языков. Система типов и правила взаимодействия изложены в CLI, общей языковой инфраструктуре, которая должна служить многим целям и мастерам.
Константная корректность редко встречается в современных языках. Лично я знаю только C ++, язык, который не портирован в CLI. Трудно обеспечить соблюдение правил на языках, для которых нет никакого синтаксиса. Такие простые вещи, как интегральные типы без знака, отсутствующие в CLS, оставили заметный след в конструкции базовых сборок.
Неизменяемость (настоящая, а не подделанная компилятором) заставляет команды MSFT думать. Он популярен, я знаю, что команда C # думала об этом. Подходит для параллелизма и т. Д. Эрик Липперт написал серию сообщений в блоге , состоящую из 11 частей, но вроде как прекратил свое существование. Слишком велик для одного парня и его аудитории. Если будет реальный шаг к его реализации, я верю, что они все продумают и заставят работать. Когда-нибудь. Какой-то язык.
Я заметил большое количество параметров, использующих структуру.
Здесь стоит упомянуть о том, что C # преувеличивает разницу между структурой и классом по сравнению с C ++, преувеличивая разницу между типами значений и ссылочными типами. В C # все классы являются ссылочными типами, а все структуры являются типами значений. В .Net все по умолчанию передается по значению.
Результатом этого различия для типов значений является то, что все типы значений копируются при передаче в функцию. Если вы передаете структуру функции, вы гарантируете, что функция не изменит исходную структуру, потому что функция работает только с копией. Добавление const к такому параметру глупо.
Ссылочные типы также передаются по значению.Или, точнее, сама ссылка передается по значению. Итак, у вас есть копия ссылки, но она указывает (относится) к тому же объекту. Таким образом, изменения, внесенные в объект функцией, сохранятся после выхода из функции.
На первый взгляд, добавление параметра const , по крайней мере, для ссылочных типов, кажется хорошей идеей. Там, где это становится немного мутным, так это с побочными эффектами. Или, скорее, как это обеспечивается? Очевидно, достаточно просто сказать, что ваш код не может использовать средства задания свойств. А как насчет других методов? Любой вызов метода может потребовать изменения объекта. Даже геттеры свойства могут иметь побочный эффект, который что-то меняет (скажем, вы реализуете функцию безопасности, чтобы отмечать, когда к чему-то в последний раз обращались). Собираетесь ли вы запретить чтение свойства из-за побочного эффекта?