Почему constness был удален из Java и C#?
Когда дело доходит до модульных тестов , я бы сосредоточился на тестировании каждого метода фильтрации отдельно. Например, если visitBinaryOperator возвращает ожидаемое значение на основе ввода и т. Д.
Я не эксперт по именованию вещей, но я бы назвал ваш тест интеграционным тестом . Здесь я бы сосредоточился на тестировании FilterOption, подготовленном внутри теста. В исходном приложении Apache Olingo создаст это FilterOption, и эта часть (должна быть) протестирована в Olingo.
Когда я работал с Apache Olingo, я часто ссылался на его репозиторий , особенно на server-test и server-tecsvc . Чтобы проверить, как все проверено в самом Олинго.
Я бы посоветовал взглянуть на FilterValidator , так как он может быть полезен для вашего интеграционного теста.
5 ответов
В этом интервью сказал Anders:
Anders Hejlsberg: Да. Относительно константы это интересно, потому что мы слышим что жалоба все время также: "Почему у Вас нет константы?" Неявный в вопросе, "Почему у Вас нет константы, которая осуществляется временем выполнения?" Это действительно, что спрашивают люди, хотя они не выходят и говорят это тот путь.
Причина, что работы константы в C++ состоят в том, потому что можно выбросить его. Если бы Вы не могли бы выбросить его, то Ваш мир высосал бы. Если Вы объявляете метод, который берет константу Bla, Вы могли передать его неконстанта Bla. Но если это наоборот, Вы не можете. Если Вы объявляете метод, который берет неконстанту Bla, Вы не можете передать его константа Bla. Таким образом, теперь Вы застреваете. Таким образом, Вам постепенно нужна версия константы всего, что не является константой, и Вы заканчиваете с теневым миром. В C++ Вы выходите сухим из воды, потому что как с чем-либо в C++ это является чисто дополнительным, хотите ли Вы эту проверку или нет. Можно просто бить constness далеко, если Вам не нравится он.
Относительно того, почему они сделали это, включенные сказали так:
http://blogs.msdn.com/ericgu/archive/2004/04/22/118238.aspx http://blogs.msdn.com/slippman/archive/2004/01/22/61712.aspx также упомянутый Raymond Chen http://blogs.msdn.com/oldnewthing/archive/2004/04/27/121049.aspx
Во много системе языка это было бы очень сложно.
Я предполагаю, прежде всего, потому что:
- это не может правильно быть осуществлено, даже в C++ (можно бросить его),
- единственная константа внизу может вызвать целую цепочку константы в дереве вызова
Оба могут быть проблематичными. Но особенно первое: если нельзя гарантировать, какое использование - это? Более оптимальные варианты могли бы быть:
- неизменные типы (или полная неизменность или неизменность фруктового мороженого)
Что касается Java, как у Вас было бы такое свойство, ведут себя? Уже существуют методы для того, чтобы сделать объекты неизменными, который является возможно лучшим способом достигнуть этого с дополнительными выгодами. На самом деле можно эмулировать поведение константы путем объявления суперкласса/суперинтерфейса, который реализует только методы, которые не изменяют состояние и затем наличие подкласса/подынтерфейса, который реализует методы видоизменения. upcasting Ваш изменяемый класс к экземпляру класса без методов записи другие биты кода не могут изменить объект, конкретно не бросая его назад к изменяемой версии (который эквивалентен выбрасыванию const).
Даже если Вы не хотите объект быть строго неизменными, если бы Вы действительно хотели (который я не рекомендовал бы), то Вы могли поместить некоторый режим 'блокировки' на него так, чтобы он мог только быть видоизменен при разблокировании. Имейте блокировать/разблокировать методы быть частными, или защищенные как соответствующие, и Вы получаете некоторый уровень управления доступом там. С другой стороны, если Вы не намереваетесь для метода, берущего его в качестве параметра изменить его вообще, передача в копии того объекта, или если копирование всего объекта слишком тяжело затем некоторый другой легкий объект данных, который содержит просто необходимую информацию. Вы могли даже использовать динамические прокси для создания прокси к объекту, которые поворачивают любые вызовы к методам мутации в без операций в секунду.
В основном уже существует целый набор способов предотвратить видоизменяемый класс, которые позволяют Вам выбрать тот, который соответствует наиболее соответственно Вашей ситуации (подсказка: выберите чистую неизменность по мере возможности, поскольку она делает объект тривиально ориентированным на многопотоковое исполнение и легче рассуждать с в целом). Нет никакой очевидной семантики для как const мог быть реализован, который будет улучшением на этих методах, это была бы другая вещь узнать, что это или испытает недостаток в гибкости или будет так гибко, что будет бесполезно.
Таким образом, если я не пропустил что-то, которое совершенно возможно.:-)
Java имеет свою собственную версию константы; финал. Joshua Bloch описывает в своем Эффективном Java, как Вы эффективно используете заключительное ключевое слово. (btw, константа является зарезервированным словом в Java для будущих несоответствий),