Если у меня есть общедоступный метод, который возвращает значение ссылочного типа, которое является закрытым полем в текущем классе, нужно ли мне возвращать его копию? В моем случае мне нужно вернуть список, но этот метод вызывается очень часто, и мой список содержит около 100 элементов. Дело в том, что если я верну одну и ту же переменную, все смогут ее изменить, но если я верну копию, производительность снизится. В моем случае я пытаюсь создать таблицу судоку, что не является быстрой процедурой. Внутренний класс SudokuTable содержит значения с их возможными значениями. Открытый класс SudokuGame обрабатывает запросы пользовательского интерфейса и создает/решает SudokuTable. Является ли хорошей практикой выбор производительности вместо принципов ООП? Если кто-то захочет создать другую библиотеку, используя мой класс SudokuTable, он не будет знать, что может нарушить ее состояние, изменив возвращаемый ею список.
Сохранение действительного состояния класса по сравнению с производительностью
Ответы (1)
Производительность и объектно-ориентированное программирование не исключают друг друга — ваш код может быть объектно-ориентированным и работать плохо и т. д.
В случае, если вы указываете здесь, я не думаю, что было бы разумно разрешать внешним частям редактировать внутреннее состояние вещи, поэтому я бы вернул массив или ReadOnlyCollection записей (может быть потенциальная возможность использовать ObservableCollection и отслеживать несанкционированное вмешательство за пределы границ и соответствующим образом «обрабатывать» это (скажем, с исключением или что-то в этом роде) - не уверен, насколько это желательно).
Оттуда вы можете рассмотреть, как вы предоставляете доступ к этим записям, пытаясь свести к минимуму потребность вызывающих абонентов в получении полной коллекции, когда все, что им нужно, это найти и вернуть конкретную.
Стоит отметить, что нередактируемая коллекция также не обязательно означает, что ее состояние нельзя изменить; если записи представлены ссылочным типом, а не типом значения, то возврат записи оставляет это открытым для подделки (потенциально, в зависимости от определения класса), поэтому вам может быть лучше со структурами для типы входа.
В конце концов, без конкретного примера того, где у вас возникают проблемы, на данный момент это немного субъективно и теоретически. Вы пытались ограничить коллекцию? И если да, то как выступление? Где были проблемы? И так далее.
Immutable Collections пространство имен. ReadOnlyCollection гарантирует, что получатель не сможет его изменить, но его может изменить создатель, имеющий доступ к базовой коллекции. ImmutableList нельзя изменить после того, как он создан (но вы все равно можете добавлять и удалять из него, он просто создает новые списки (он разделяет внутреннее состояние между списками, поэтому новые списки не занимают много памяти)).
- person Scott Chamberlain; 16.03.2014
