파일 이름을 메소드로 전달할 때 FileInfo 또는 일반 파일 이름을 사용해야합니까?

StackOverflow https://stackoverflow.com/questions/912662

  •  06-09-2019
  •  | 
  •  

문제

글쎄, 제목은 모든 것을 말합니다. 파일 이름을 메소드로 전달할 때 FileInfo 객체 또는 일반 파일 이름 (String)을 사용해야합니까? 왜 내가 하나를 선호합니까?

내 동료 중 일부는 다음과 같은 방법을 작성하는 것을 좋아합니다.

  • void 내보내기 (fileInfo fileInfo)

다음보다 낫습니까?

  • void Export (String filename)

감사!

도움이 되었습니까?

해결책

나는 보통 a를 사용합니다 string - 대부분의 경우 더 간단합니다. 그렇지 않으면 새로운 것을 만들 수 있습니다 FileInfo 처음에 문자열에서.

메소드를 작성하는 경우 항상 오버로드를 제공하여 두 가지를 모두 허용 할 수 있습니다.

물론, 당신이 그것을 어디에 부르고 있는지 알고 있다면, 당신은 보통 가지다 ㅏ FileInfo a보다는 string, 그것은 다른 문제입니다.

동료의 관점을 볼 수 있습니다. FileInfo 매개 변수를 표현하는 "클리너"방법입니다. 제 생각에는 string 그래도 더 실용적인 접근법입니다 :)

다른 팁

일반적으로 나는 문자열을 전달합니다. 그러나 모든 사람을 행복하게 만들기 위해이 방법을 과부하시킬 수 있습니다.

차이점은 주로 약간의 점검이 진행되고 있다는 것입니다. FileInfo 생성자는 NULL 또는 명확하게 유효하지 않은 매개 변수를 검사합니다. 다른 일이 몇 가지 있습니다. FileInfo를 기본적으로 복용하면 코드와 달리 호출 코드에 FileInfo 생성자의 예외를 처리하는 데 도움이됩니다.

다음은 생성자가 던질 수있는 내용을 보여주는 FileInfo 생성자의 MSDN 참조입니다.

http://msdn.microsoft.com/en-us/library/system.io.fileinfo.fileinfo.aspx

나는 그것이 의존한다고 말합니다 :) 클래스 파일의 많은 정적 파일 작업은 파일 이름으로 여러 가지를 허용합니다. 파일의 추상화는 .NET 프레임 워크에서 종종 유용하지 않으므로 문자열을 사용하고 인수 이름을 표시하는 것에 편향되어 있습니다.

이 동료들과 관련된 코드를 연구하고 있다면 FileInfo를 사용합니다. 실제로는 중요하지 않지만 코드를 작성하여 다른 사람들이 유지를 줄이고 일관성을 높이며 일반적으로 사람들을 행복하게 만듭니다.

나는 내가 사용한다는 아이디어를 싫어한다고 지적 할 것이다. FileInfo McWafflestix가 지적한대로 호출 함수에 대한 유효성에 대한 수표의 유효성을 배치하기 위해. 호출 함수와 호출 된 함수 사이에 무언가가 깨지면 잡히지 않을 것입니다. 문자열을 사용하면 반드시 잡히는 것은 아닙니다 ... 그러나 적어도 문제가 발생할 수있는 곳을 분명히합니다. 그리고 어쨌든 불리는 방법에서 그러한 예외를 포착하고 싶을 것입니다. 분명히 당신은 실제 기능이 될 때까지 파일을 열고 읽기/쓰기를 시작하지 않을 것입니다 (PileInfo와 String은 아마도 잘못된 선택 일 것입니다.

FileInfo는 문자열보다 데이터 유형의 의도를 보여주기 위해 더 많은 기능을 수행합니다. 그리고 그것은 거의 항상 좋은 것입니다. 그러나 대부분의 .NET 프레임 워크 자체를 포함하여 파일 이름을 문자열로 전달하는 데 전례가 많이 있습니다. 파일 이름은 문자열입니다. 아마도 발신자가 FileInfo 객체를 사용하여 호출 코드를 강제하여 예외를 전달하는 데 부담을주는 대신 파일 이름 (예외 처리)을 유효성을 강제로 사용하게 할 것입니다.

확실히, 메소드 과부하를 포함하여 전달되는 파일 이름을 확인하는 한 모든 의심을 제거 할 수 있습니다.

파일 이름이 똑같은 일을한다면 충분할 것이라고 생각합니다.

  1. 문자열은 경로가 아닙니다. 따라서 문자열은 경로를 나타내는 가장 좋은 방법이 아닙니다.
  2. FileInfo는 또한 경로가 아니며 의미 적으로 파일을 나타냅니다.

따라서 MS가 경로 개체를 제공하는 경우 더 나을 것입니다. :) 또는 특히 내부 코드 인 경우 직접 만들 수 있습니다. 이런 식으로 당신은 그들과 함께 일할 때마다 경로 인수를 확인할 필요가 없습니다. 나는 종종 다른 찌르기, nullstring, idstring (Case Insensitive)을 나타내는 많은 구조를 가지고 있습니다. 이것이 단순히 코드를 만든다고 생각합니다.

나는 증기를 사용하는 협약을 따를 것입니다. 이것이 내가 대부분의 I/O가 수행되는 방식입니다. 나에게 의미가 있습니다.

void Export(string s) 
{ 
  Stream fs = new FileStream(s); //think this is correct
  Export(fs); 
}
void Export(Stream s) 
{
  s.Write ( ... );
  ...
}

나는 파일 인포가 나에게 그렇게 유용한 적이 없다. Filestream, MemoryStream 등이 될 수있는 String 또는 사용 스트림을 사용하십시오.

평소와 같이, 그것은 달라집니다. 가장 기본적인 사례를 제외하고는 FileInfo를 사용하면 거의 네거티브가없는 많은 혜택을 제공한다고 말합니다. 엄격한 OO Dogma는 파일 (경로, 생성 날짜, 수정 날짜 등)에 대한 정보가 FileInfo와 같은 클래스 내에서 캡슐화되어야한다고 말합니다. 이렇게하면 도로가 더 복잡한 동작이 필요한 경우 더 많은 유연성을 제공합니다. FileInfo에 대해 코드를 작성하는 경우 변경 해야하는 경우 거의 항상 깨끗하고 버그가 덜 발생합니다.

더 복잡한 행동이 필요한 시나리오를 절대적으로 생각할 수없고 실제로 당신을 버릴 것입니다. 계속해서 문자열을 사용하십시오.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top