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

C# API Design #2, Naming

새해 강의를 찾다가 아래 강의를 듣게 됨.

https://www.udemy.com/api-in-csharp/learn/v4/overview

API design에 대한 책은 많지만 C#에 대해서 특화된 내용이 없어서 좀 아쉽던 차에

이런 강의를 보게 됨. 하지만 강의 내용은 평범하다.

보다가 기억에 남는 것을 간단히 정리함.

하지만 강의를 들어야 모든 내용을 이해할 수 있으니 필요하면 구입해서 듣는 것도 방법임.

[Naming]

사실 아래 Coding convention을 참고해도 됨
http://www.dofactory.com/reference/csharp-coding-standards

올바른? naming을 사용하는 것은 code readability나 maintenance를 위해 꼭 필요하다.

. 영어 단어를 사용하되 의미가 맞고 적절한 어순으로 사용하라.
. 아재들이 사용하는 헝가리안 표기법(Hungarian notation)은 사용하지 말라.
. C coding style 도 별로임. “i_cnt”, “str_name”.
. 변수, 함수 사용 시 짝을 맞춰 사용하라. (locked/unlocked, first/last 같이)
. private/protected field, parameters들은 Camel casing, 그외는 Pascal casing
. 약어는 2글자 이하는 모두 대문자로 3글자 이상은 casing을 따른다.
  하지만 예외는 있음 : BitFlag(bitFlag), Email(email), Id(id), Ok(ok), Pi(pi), Metadata(metadata)
. 상속 받는 class들의 suffix를 따른다.
. 하나씩만 사용하는 enumeration은 단수형 이름으로 복수개를 한번에 사용할 수 있는 것은 복수형 이름으로...

무엇보다 code는 readable 하게 작성되어야 함.

C# API Design #1

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

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

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

. API는 functionality의 모음으로 볼 수 있다.
. Nice APIs, nasty APIs는 있지만 prefect, definitely APIs는 없다.
. Private API는 잘 관리되는 동물원과 같고 Public API는 정글과 같다.

괜찮은 API의 특성에 대해서 말하고 있음
. Simplicity, Expressiveness(표현력) and Compromises(타협), Extensibility, Open-Closed Principle (OCP), Consistency

. API의 Simplicity는 API 기능과 반비례함.
. Simplicity를 측정하는 방법은 없지만 동료에게 사용하게 해보고 API를 사용하는데 얼마의 시간이 걸리는지 확인해 보는 것도 방법
. API를 만들기 위한 resource들은 제한적이므로 적정한 선에서 API를 제공할 수 밖에 없음.
. Universal APIs 따위 만들 수 없음.

API design 방법을 말하고 있는데 몇개 추려보면
. API는 최대한 간단하게 만들어라.
. API를 간단히 배워 사용할 수 있게 하라.
. 간단한 constructor들을 제공하되 필요한 parameter들에 대해 기본값을 제공하는 것도 방법
. Exception을 발생 시킬 때는 뭘 고쳐야 할지 알려줘라.
. API 자체가 어떻게 사용할 수 있는지 알 수 있도록 만들어라.
. Decent documentation

[Links] Android app architecture links

MVC and MVP architectural patterns in Android – part 1
: http://www.techyourchance.com/mvc-and-mvp-architectural-patterns-in-android-part-1/

Model-View-Presenter Architecture in Android Applications
: http://macoscope.com/blog/model-view-presenter-architecture-in-android-applications/

Android Application Architecture
: https://labs.ribot.co.uk/android-application-architecture-8b6e34acda65

Android Architecture Blueprints [beta]
: https://github.com/googlesamples/android-architecture