Препятствование тому, чтобы методы были наследованы
Вам необходимо указать имя файла назначения, а также каталог:
File.Move("file.zip", Path.Combine(archiveFolder, "file.zip"));
6 ответов
Я заново продумал бы потребность в этом.
При использовании наследования Вы предполагаете, что "Панель" ЯВЛЯЕТСЯ "Нечто". Если "Панелью" всегда является "Нечто", методы, которые работают над "Нечто", должны также работать над "Панелью".
Если бы это не имеет место, я переделал бы это как закрытый метод. Публично, Панелью должно всегда быть Нечто.
Только взять этот шаг вперед -
Если бы Вы могли бы сделать это, вещи стали бы очень сложными. У Вас могли быть ситуации где:
Foo myBar = new Bar(); // This is legal
myBar.FooSpecificMethod(); // What should this do?
// It's declared a Foo, but is acutally a Bar
Можно на самом деле вызвать это поведение с помощью отражения, все же. Я думаю, что это - плохая идея, но FooSpecificMethod () мог проверить тип этого, и если это не typeof (Нечто), выдайте исключение. Это очень сбивало бы с толку, и имело бы очень неприятный запах.
Редактирование в ответ на редактирование вопроса:
Нет никакого пути к компилятору для осуществления то, что Вы спрашиваете. Если Вы действительно хотите вынудить компилятор проверить это и предотвратить это, действительно необходимо считать создание Foo запечатанный класс. Вы могли использовать другие дополнительные методы, чем разделение на подклассы в этом случае.
Например, Вы могли бы хотеть рассмотреть использование событий или делегатов для расширения поведения вместо того, чтобы позволить объекту быть подклассами.
Попытка сделать, что Вы выполняете, в основном пытается предотвратить главные цели наследования.
Brian прямо о Замене Liskov (upmodded). И Тростник прямо о "-" (также upmodded); на самом деле они оба говорят Вам то же самое.
Ваши открытые методы являются контрактом с пользователями Вашего класса Foo, говоря, что, "можно всегда" называть те методы на Foo.
Разделение на подклассы Foo означает, что Вы говорите, что Подкласс, например, Панель, всегда приемлем для использования, где Нечто могло использоваться. В частности, это означает наследование не (обязательно) реализации Foo (можно переопределить это, или Foo может быть абстрактным и не дать конкретную реализацию для метода).
Наследование реализации (если таковые имеются) является деталью; то, что Вы действительно наследовали, является открытым интерфейсом, контрактом, обещанием пользователям, что Панель может использоваться как Нечто.
Действительно, они могут даже не знать, что у них есть Панель, не Нечто: если я делаю FooFactory, и я пишу его Foo* getAFoo () для возврата указателя на Панель, они никогда не могут знать, и sholdn't имеют к.
Когда Вы нарушаете те условия контракта, Вы повреждаете Объектную Ориентацию. (И классы Набора Java, путем выдачи исключений NotSupported, полностью повреждают OO - пользователи больше не могут использовать так называемые подклассы полиморфно. Это - плохой, плохой дизайн, который заставил сильные головные боли для многих многие пользователи Java, не что-то эмулировать.)
Если существует открытый метод, который не могут использовать подклассы Foo, то тот метод не должен быть в Foo, это должно быть в подклассе Foo, и другие подклассы должны произойти от Foo.
Теперь, это НЕ означает, что все методы в Foo должны быть вызываемыми на подклассах. Нет, я не противоречу мне. Непубличные методы не являются частью открытого интерфейса класса.
Если Вы хотите метод в Foo, которого нельзя позвонить на Панели и не должен быть публично вызываемым в Foo, затем сделать тот метод частным или защищенным.
Нет, это нарушило бы принцип замены Лисков.
Практично, у Вас может или быть он, "бросают NotImplementedException ()" в Панели, или удаляют метод от Foo и спускают его к подклассам, к которым это применяется.
Вы могли сделать закрытую функцию и затем назвать ее с помощью отражения. Вероятно, немного за борт. Так или иначе просто поместите функцию в свой базовый класс, наряду с комментариями, говоря, что это нужно только назвать от базового класса. Возможно, даже те хорошие комментарии///, которые обнаруживаются с intellisense. Затем Вы могли бы получить ошибку, но затем хорошо, Вы будете всегда получать ошибки, и лучшим, который можно сделать, является документ эта ситуация, чтобы стараться избегать ее.
Создание частной функции будет препятствовать тому, чтобы он был назван подклассами непосредственно.
Если Вы говорите о виртуальных функциях, что Вы не хотите быть перегруженными, отмечая функцию, как изолировано в точке, что Вы хотите "заблокировать" функциональные работы.
Даже если это - закрытая функция, это могло бы все еще назвать отражение.
Вы могли также объявить функцию в интерфейсе и явно реализовать интерфейс на классе, который вынудит Вас бросить его к интерфейсу для использования функции.
Решение, которое я в итоге использовал, заключалось в создании общедоступного внутреннего унаследованного класса. Таким образом, он может получить доступ к закрытым переменным базового класса (при необходимости), и мне не нужно открывать публично какие-либо из этих частных переменных или функций (чего я не хочу).
Спасибо, за все ваши советы, это заставило меня переосмыслить, что именно мне нужно от этой договоренности.