닷넷 API 관습

.net 의 BCL 혹은 주요 프레임워크들의 구현을 보면 일종의 패턴 같은 것들이 눈에 띕니다.

눈에 띄거나, 따라해봄직한 패턴들을 정리하는 슬로그입니다.

return Nullable vs throw Exception

메서드를 작성하다 보면, 반환형을 nullable 타입으로 할 것인지, exception 을 throw 할 것이지 선뜻 결정하기 곤란한 경우가 있습니다.

닷넷은 이런 경우, 메서드 오버로드 보다는 식별자로 구분되는 메서드 쌍을 제공하는 경우가 많습니다.

non-nullable return or thow 버전

메서드는 non-nullable 타입을 반환하고, 내부에 exception 을 유발하는 코드가 있습니다.
이 경우 메서드 이름에 “Required” 라는 단어가 들어갑니다.

Far GetRequiredFar

우리가 이 패턴을 채택하는 경우, 예외를 두 가지로 이용할 수 있습니다.

  1. 코드 흐름 상 예외가 있을 수 없다고 판단한 경우
    미처 생각하지 못한 부분을 캐치하여, 완성도를 높입니다.
  2. 외부 코드에서의 예외 발생
    외부 코드의 사용법과 주의점을 다시 살핍니다.

nullable return and no throw 버전

메서드는 nullable 타입을 반환하고, 내부에서 exception 을 처리하여 외부로 표출하지 않는데, Requried가 없는 메서드 이름이 사용됩니다.

Far? GetFar

이 패턴을 채택할 때는 가급적 모든 예외를 억눌러야 합니다.
클라이언트 코드 입장에서는 null 검사만 해도 되기에 보다 간편하지만, 내부 구현 시, 모든 예외에 발생 가능성에 대한 확신이 있어야 합니다.

10개의 좋아요

실패시 null 반환은 Try + DoSomething,
예외 발생 버전은 그냥 DoSomething로 하는 명명도 있습니다

2개의 좋아요

추론을 해봤는데, 대체적으로 '자주 사용’되는 메소드가 이름이 짧은 편인것 같습니다.

null이 일반적으로 허용되는 가져오는 기능의 경우
GetSomething(), 반드시 필요한 경우 GetRequiredSomething()

반대로 가져올 때 대부분 실패하지 않을 것으로 기대되는 기능의 경우는
예외 버전이 GetSomething(), 실패시 null 이 TryGetSomething()

TryParse vs TryGetValue

A.TryParse( _ , out A x)

TryParse 는 입력 값을 통해 A 객체를 생성하는데, 보통 static 메서드인 경우가 많습니다.

이러한 메서드를 호출할 때는 반드시 메서드 식별자에 형식(A)을 붙여야 하기 때문에, var 를 사용해도 x 의 형식을 바로 알 수 있습니다.

var s = "...";

if( !SpaceShipCodeValue.TryParse(s, our var x) )  // var : SpaceShipCodeValue
   return null;
// ...

a.TryGetValue( _ , out B x)

TryGetValue 메서드는 인스턴스 메서드인 경우가 대부분인데, TryParse 와는 달리, 코드 만으로, x의 형식인 B를 유추하기 어렵습니다.

var s = "...";

if( !WarfHistory.TryGetValue(s, our var x) )
   return null;
// ...

이 경우, 귀찮더라도, var 대신에 형식의 full name 을 지정하는 게 가독성 측면에서 좋습니다.

if( !WarfHistory.TryGetValue(s, out StarWars.Galaxy.PlanetCoordinate x) )
   return null;
// ...
3개의 좋아요