- 1
- 2
- 3
- 4
if (!File.Exists(filePath))
{
throw new FileNotFoundException("File is not a file!", filePath);
}
Си диез / Говнокод #11307
0
Вот такая вот философия шестилетней давности. Собственное говно :)
Запостил: 
anmiles,
(Updated )
Если уж и тырить жабу, то в полном объеме.
почему папка и файл должны иметь общего наследника? Composition over Inheritance же.
А вот почему
Они явно не могут в абстракцию и наследование.
http://msdn.microsoft.com/en-us/library/system.io.directory.aspx
>кстати, тогда такой вопрос - а перечисление файлов и папок реализовано отдельными функциями в духе
Сразу отвечая и на твой вопрос.
http://msdn.microsoft.com/en-us/library/system.io.filesysteminfo(v=vs.80).aspx
FileSystemInfo Class
Provides the base class for both FileInfo and DirectoryInfo objects.
http://msdn.microsoft.com/ru-ru/library/system.io.file.exists%28v=vs.90%29.aspx
И тогда в этом послании "File is not a file!" вырисовывается некий сакральный смысл.
Поставить вижуалстудию. Очень быстро, да.
P.S. Отправлял бы на MSDN тогда уж, ибо до него добраться явно проще, чем до IDE.
>А объект File же может быть папкой, или не?
возникать не должно.
Ну так ни я, ни борманд, ни π на решётке не пишем
//ОП
>Ну тогда это не говнокод
Ваша логика безупречна.
А на счет Сишарпа - искать лень, но если уж Виста и более новые поддерживают симлинки, я думаю, они бы чего-нибудь в СДК добавили для их определения. Как жеж программы писать тогда?]
Ха, нашел быстрее чем думал, через p-invoke... мда...
У нас есть since 1.2 канонiчные методы.
Ну почему это? Как раз наследование тут вполне подходит:
делаем нового наследника от класса File - типа SymLinkFile. И всё.
Внутри пишем нужную логику, но внешне это тот же File.
>public File getCanonicalFile()
>Equivalent to new File(this.getCanonicalPath()).
>The canonical pathname string denoting the same file or directory as this abstract pathname
Если прочитать другой мой пост http://govnokod.ru/11307#comment144600, то напрашивается ответ:
new File(this.getCanonicalPath())
+
isDirectory()
=
file.getCanonicalFile().isDirectory()
Объясняю:
File можно наследовать если хочется
>делаем нового наследника от класса File - типа SymLinkFile
и оборачиваем им getCanonicalFile().
А в C#
public sealed class FileInfo : FileSystemInfo
public sealed class DirectoryInfo : FileSystemInfo
Если хочется то в яве _можно_ сделать наследника от File.
И тогда new SymLinkFile(path) будет прозрачно отсылать нас к файлу или папке вместо path, который является ссылкой. Внешне же это будет наш File.
>То, что вы демонстритуете не имеет отношения
Это я указываю способ на то как это можно осуществить.
Вот еще раз, повторюсь
>public sealed class FileInfo : FileSystemInfo
Есть цепочка наследования:
Directory <- File
Пытаемся добавить симлинк:
SymLink <- File
Теперь SymLink не может быть Directory потому, что уже наследует File.
Исправляем:
SymLink <- Directory <- File
но, естественно, не все симлинки являются директориями.
Исправляем:
SymLinkDirectory <- SymLink <- AbstractFile
Directory <- File <- AbstracFile
Все равно, типы SymLinkDirectory и Directory не совместимы.
и т.д.
Т.е. нету и в принципе не может быть ситуации в системе не поддерживающей множественное наследование, где возможно реализовать отношение между файлами директориями и симлинками, которое наблюдается в жизни.
А то, что это можно сделать кучей других способов - как бы и так понятно.
А что в ОП посте?
А о чем мы вообще говорили изначально?
>ну да не важно в данном случае.
Очень важно. Речь шла о нем.
>в системе не поддерживающей множественное наследование
Может. Интерфейсы вы еще не проходили.
К тому же я привел пример.
Мой пост про Яву и Наследование. Про C# и наследование я не говорил.
Интерфейсы - не наследование. Интерфейсы, это другой способ решить задачу.
Не хочется думать и внимательно читать чужие посты.
>Мой пост про Яву и Наследование.
Я привел пример на Яве и Наследованием. И даже _без интерфейсов_
>SymLink <- Directory <- File
Бгг 😀
Гениальная находка в области проектирования - наследовать симлинк от папки.
>не все симлинки являются директориями.
Симлинки ВООБЩЕ не являются директориями.
И без наследования, просто с вызовом какого-то метода - таких способов миллион, речь про наследование, а не про то как можно решить проблему без него.
Симлинки могут указывать на директории, этого достаточно для того, чтобы расценивать их как директории, для того такая возможность и существует. Если вас это чем-то не устраивает - то, например, разработчиков графического интерфейса всяких проводников по файловой системе такой подход вполне устраивал. Он так же устраивает другие языки (тот же bash и eLisp, например):
Потому SymLink <: File очень даже подходит. В конце концов, symlink - это просто файл, в котором хранится путь + флажок в inode.
Следуя вашему описаний симлинка - директория - тоже файл, и тут мы возвращаемся к проблеме типов, что и директория - файл и симлинк файл, но бывают симлинки, которые нужно расценивать как директории, а бывают такие, что нет - и тут наследование не помогает, потому что кто-то решил, что множественное наследование "не нужно" и придумал множество обходных путей как бороться с отсутсвием множественного наследования. Но это конечно замечательно, потому что - нет объяснения, просто так, потому что думать не хочется.
к уже существующим:
http://govnokod.ru/11307#comment144618