{ GameCook }

람다 식 (Lambda Expression)

제네릭 (Generic)

미결정 상태의 데이타 타입을 클라이언트 코드에서 클래스 또는 메서드로 선언하고 인스턴스화할 때

지정하는 유연한 타입 지정방식이다. (.NET Framework버전 2.0 이후 형식 매개변수(Type Parameter)라는 개념으로 새롭게 도입되었다.)

제네릭 도입 이전에는 일반화된 알고리즘을 정의하기 위해서 모든 멤버들을 object 데이터 타입으로 다루어야만 했다.

IEnumerable 컬렉션

인터페이스는 상속받는 새로운 클래스가 기본 클래스로부터 함수를 구현해주는 약속이다.

델리게이트(delegate)

이벤트(Event)

out 키워드

Ref 키워드

컴파일타임 상수 vs 런타임 상수 

변수와 달리 한번 정의해 둔 값으로서 더 이상 변경할 필요가 없는 것들을 의미한다.(ex 원주율)

Const -  컴파일타임에 처리 (컴파일 타임에 변수가 값으로 대체된다)

인터페이스를 제외한 데이터 형식은 (특별한 타입이 정해져 있지 않은 참조 타입인) Object 타입으로부터 모두 파생된다.

즉, 값 타입인 int 형도 더 큰 범주에 속해 있는 Object의 자식 객체라는 이야기가 된다.

서로 다른 타입인 값 타입과 참조 타입은 Object 타입을 매개로 하여 박싱과 언박싱을 통해 서로에게 전달될 수 있다.

박싱 : 값 타입 -> 참조 타입

값 타입은 이 익명의 참조 타입 내부에 저장

언박싱 : 값 타입 -> 참조 타입

박싱되어 있는 참조 타입의 객체로부터 값 타입 객체의 복사본을 가져온다.

"박싱과 언박싱은 System.Object 타입이나 인터페이스 타입이 필요한 곳에서 값 타입을 사용하기 위해 반드시 필요한 매커니즘이다.

하지만 박싱과 언박싱은 성능에 좋지 않은 영향을 미친다. 때로는 박싱과 언박싱을 수행하는 과정에서 임시 객체가 생성되기도 하는데

간혹 이로 인해 예상치 못한 버그가 발생하기도 한다. 따라서 박싱과 언박싱은 가능한 피하는 것이 좋다." 라고 -Effective C# 에서 설명함.

C#은 컴파일 시간에 정적으로 형식화되므로 변수가 선언된 이후 다시 선언되거나 다른 형식의 값을 저장하는 데 사용할 수 없다.

(이말인즉슨 int 형을 string 형으로 변환할 수는 없다는 의미이다.)

그러나 다른 형식의 변수 또는 메서드 매개 변수에 값을 복사해야 하는 경우도 있다.

(예를 들어 매개 변수가 float 으로 형식화된 메서드에 int값을 가진 정수형 변수를 전달하는 경우)

 C#에서 형식 변환은 다음의 4가지 방법에 의해 수행된다.

• 암시적 변환   
• 명시적 변환   
• 사용자 정의 변환 
• 도우미 클래스를 사용한 변환

암시적변환

그래서 cast란 것을 해야하는데 (cast : 컴파일러에서 (<Type>) 캐스트라는 특수구문을 거쳐 명시적 변환을 수행)

이것은 변환을 수행하고자 할때 어떤 데이터의 손실 가능성을 짐작해 컴파일러에게 명시적으로 알리는 방법이다.

Value type

primitive Type(int, float, bool, char 와 같은 기본 데이터 타입)과 구조체가 이에 해당한다.

변수의 선언과 동시에 값을 할당할 수 있으며 스텍에 메모리가 생성된다. 이렇게 단일한 공간에 

생선된 데이터는 직접적이며 변수의 대입이나 매개변수로 데이타를 전달할 때 메모리 복사가 일어난다.

Reference type

Class, String, Object (이것들과 더불어 배열은 그 구성요소의 형식과 상관없이 항상 참조 형식이다.)

->말로 다시 풀이해보자면 타릭이라는 기존의 normalPick이 trollPick이라는 새로운 별칭을 얻었고 
그동안 trollPick의 대명사로 불렸던 마스터 이는 이제 어떤 참조로도 형용할 방법이 없어진 것과 같다.
이렇게 객체 정보를 어떤 변수에서도 참조하지 않게 되면 시스템에서는 그 객체를 가비지 컬렉션(Garbagecollection)의 대상으로 표시하게 되고
더 이상 참조되지 않는 객체는 제거되며 그 객체가 점유하고 있던 메모리 공간을 회수해간다.
그런데 이 Garbage collection은 상당히 비용이 큰 연산이기 때문에 특별한 경우를 제외하고 최대한 이런 작업은 줄이도록 노력해야 한다.