C# API Design #3, Implementing

새해 강의를 찾다가 아래 강의를 듣게 됨.
https://www.udemy.com/api-in-csharp/learn/v4/overview

API design에 대한 책은 많지만 C#에 대해서 특화된 내용이 없어서 좀 아쉽던 차에
이런 강의를 보게 됨. 하지만 강의 내용은 평범하다.

보다가 기억에 남는 것을 간단히 정리함.
하지만 강의를 들어야 모든 내용을 이해할 수 있으니 필요하면 구입해서 듣는 것도 방법임.


[Designing and Implementing Types and their Members]


. struct, class
struct와 class의 차이에 대해서 설명을 하는데
struct는 value type, class는 reference type이라는 것,
struct를 property, readonly, 일반 변수로 사용할 때 조심해야 할 것은
property의 getter나 readonly는 변수를 복사(value type)해서 전달하므로 변수를 변경해도 실제 변수에 영향을 미치지는 않는다고함.
그래서 struct를 사용하려는 객체는 불변값을 가지는

컴파일러는 property(get)에 대해 대충 아래처럼 코드를 생성함

private Mutable ☆ ☆ ☆; // private backing field
              // 컴파일러에서 생성, 코드에서 접근 불가

public Mutable get_PropertyMutable()   // get; 컴파일러 생성
{
return ☆ ☆ ☆;
}

get_PropertyMutable은 풀어서 보면 대략 이런 느낌?

private Mutable ☆ ☆ ☆; 
public Mutable get_PropertyMutable()
{
Mutable temp = ☆ ☆ ☆;
return temp;
}


. Abstract class는 default 구현을 두고 필요한 구현만 상속 class에 맡김
Interface는 상속 class의 형태(prototype)를 강제하고 모든 구현을 맡김
 : Interface는 API client 입장에서 보면 API 사용 시 유연하고
API developer 입장에서 보면 API 구현 시 융통성이 없음.
 : Abstract class는 API client 입장에서 보면 API 사용 시 융통성이 없고
API developer 입장에서 보면 API 구현이 유연함.


. Abstract class에는 constructor를 protect로 만들어라. 실제로 Instance 생성이 불가한 abstract class에 public constructor는 말이 안됨.
https://docs.microsoft.com/ko-kr/dotnet/standard/design-guidelines/abstract-class


. Constructor에서 virtual method를 호출하지 마라.
실제 상속된 class의 virtual method에서 내부의 변수를 참조할 경우 부모의 constructor가 수행되는 중에는 자식의 constructor가 호출되지 않는 상태라 변수가 초기화가 안되어 있을 수 있다.


. Optional parameter 사용하는 API를 만들 시 아래 article을 꼭 참조하라.
: https://haacked.com/archive/2010/08/10/versioning-issues-with-optional-arguments.aspx
: http://codebetter.com/2011/01/11/c-in-depth-optional-parameters-and-named-arguments-2/

. Optional parameters는 빌드 된 IL이 default value를 포함하게 함
 : library에서 default value를 사용하는 API 사용 시 library와 API client 코드가 모두 재 빌드 되어야 default value가 변경 됨. ㅜㅜ

. Overload 된 methods들을 선택할 때
optional parameter가 없는 함수 중 동일한 parameter 개수의 함수를 선택.
없다면 optional parameter를 가진 함수 중에서 일치하는 함수를 선택한다.
이 때 API들의 parameter 중 default value를 가지고 있지 않는 개수가 동일한 경우 같은 함수로 취급된다.


.Constructor의 경우 간략한 작업을 하도록 하고
 생성 시 parameter 부족이나 초기화에 문제가 발생한다면 exception을 발생 시키는 것도 방법임. 하지만 static constructors에서 exception을 발생시키면 노답.


. Finalize를 구현하면
Finalize될 object들을 관리하는 overhead 발생하고
Finalize 시점을 예측할 수 없어 과연 resource 해제여부도 불투명함.
그래서 unmanaged resource에 대해
IDisposable을 사용하고 IDisposable 사용 시 class 상속을 허용하지 않는 것이 좋지 않을까?
https://msdn.microsoft.com/ko-kr/library/system.idisposable(v=vs.110).aspx