[객체지향설계] 9/19 이론

Class Declaration

클래스 선언 문법.

 

Object creation

객체 생성

암시적-명시적으로 생성할 수 있다.

 

문자열 인자만을 받는 객체라면 그냥 Car car = std::string("mycar") 도 가능하다. (암시적)

Car car = (Car) "mycar"도 가능. (명시적)

 

Access Modifier

private 밖에서는 접근할 수 없는 나의 것. 객체만이 갖고 있는 것.

protected private이 더 강력하다. 가족을 지킨다. 외부에는 공유하지 않지만 자식(child)에게는 줄 수 있다. - 상속에 관련함.

public 누구나 접근할 수 있다. 일반적으로 간단하게 만든다면, 모든 멤버 펑션은 퍼블릭, 멤버 필드는 프라이빗.

외부에 공개/비공개를 구분.

 

실행하다 죽는 게 아닌 컴파일 도중에 체크해서 오류를 만들어줌. Access Modifier.

 

참고 : IDE를 쓰는 건 좋다. 개발을 도와주니까. 하지만, 실행기가 아니다. 에디터일 뿐이다. 실제 프로그램을 실행하게 하는 역할은 다른 것이다.

 

Constructor 생성자.

 객체를 만들 때 항상 호출이 되는 함수이다. 그 클래스의 객체를 만들 때는 항상 생성자가 불려진다. 생성되는 객체를 초기화하는 역할을 수행한다. 리턴 타입은 없다.

 *생성자가 호출이 되면 이니셜라이제이션 리스트가 먼저 수행되고, 그 다음 몸체가 실행된다.

 

파라미터를 받지 않는 것을 Default Constructor 라고 한다. 인자가 필요 없다.

자바에서는 디폴트에 옵션을 줄 수 있다. (아무 인자를 안 줘도 된다.)

 

모든 클래스는 항상 생성자를 가지게 된다. 객체를 만들기 위해서는 생성자가 호출이 되어야 한다.

인자를 하나도 받지 않는, 아무것도 하지 않는 생성자를 만들 수 있다. 상속이 있다면 무언가를 할 것이다. 멤버 필드를 자동으로 초기화하는 코드를 넣기도 한다. (인자를 아무것도 안 받는 컨스트럭터 Class door)

 

교수님 설명 중에 default 생성자가 필요한 경우를 다시 듣고 정리하도록.

 

implicit conversion Constructror

explicit이라는 키워드가 없다면 implicit이다.

생성자인데 파라미터 받고 

 

Explicit conversion Constructor 

explicit이라는 키워드가 있다. 이 키워드가 무엇을 하는지.

왜 파라미터가 하나여야만 했는가. 여담이지만 implicit conversion에서 여러 개를 못 넣었다.

explicit이라는 키워드 하나로는 런타임에서는 문제 없지만, implicit한 경우가 있는 경우, 컴파일에서부터 문제가 발생할 수도 있다.

 

Copy Constructor

모든 클래스는 카피 컨스트럭터를 하나 갖고 있다. 우리가 정의하지 않았을 때 만들어진다. 우리가 만들었다면 안 만들어진다. default 컨스트럭터도 컴파일러가 만들어준다. 아무 생성자도 없을 경우에 그렇다. 아무 것도 없을 때만 디폴트 컨스트럭터를 만들어준다.

카피 컨스트럭터는 다른 컨스트럭터가 있는 건 상관이 없고, 카피 컨스트럭터가 없으면 컴파일러가 만들어준다. 

디폴트도 다른 것도 없다. 그러면 카피 컨스트럭터만 있다면, 컴파일러는 디폴트 컨스터럭터를 만들지 않는다. 그런데, 다른 컨스트럭터는 다 있는데, 카피 컨스트럭터가 없으면 그 때 컴파일러가 카피 컨스트럭터를 만든다.

 여기서 만드는 것은 얕은 복사를 한다. (Shallow Copy 다시 정리.) 모든 멤버 필드를 복사하는 카피 컨스트럭터를 만들어진다.

 

자바랑 다르다. Car x = new Car();  Car y = x; x==y ? => 같은 것이다. 객체에서는 포인터 같은 개념이다.

c++ 은 Car x(); Car y = x; x==y? => 다른 것이다.    자바와 다른 점이다. 기억해두자.

 

this는 수신자 객체를 가리키는 키워드이다.

자바에서는 . 을 c++에서는 ->으로 한다. this는 포인터이다.

생략해도 되지만, 헷갈릴 수 있기 때문에 한다.

 

클래스들 간에 관계를 만들 수 있다. (친구 설명 다시 듣기. 딴 생각)

C++에서의 친구는 나의 모든 것을 볼 수 있다. private이라도 friend를 설정하면 friend는 private도 볼 수 있다. 물론 friend가 나를 friend를 설정하지 않으면 나는 못 본다. 빌더 패턴을 이용해서 friend로 깔끔하게 만들 수 있다. 유용하지만 자주 쓰면 좋지는 않다.

friend는 일방적이다.

 

선언과 정의의 차이점.

선언은 생김새, 정의는 동작.

 

헤더 파일은 선언만, 소스 파일은 정의를 쓴다.

헤더 파일의 #ifndef #endif는 여러 번 정의되는 것을 방지하는 매크로이다. 같은 헤더파일을 공유하는 소스파일 두 개가 여러 번 선언되면 충돌이 발생하기 때문에 반드시 헤더가드가 있어야 한다.

 

 

 

---

클래스 이름은 파스칼 케이스로 만들기.

클래스는 기본적으로 프라이빗, 스트럭트는 기본적으로 퍼블릭. 그 외에는 모두 동일.

멤버 필드를 쓸 때 스네이크 케이스 및 언더스코어'_' 시험에 나온다. 실습할 때 잘 지켜서 하면 틀리지 않는다.

 

자바에서는 프라이빗 먼저 쓰고 그 다음.. C++은 퍼블릭부터 프라이빗으로 써야 한다.

자바는 선언과 정의를 분리하지 않고 같이 쓴다. 한 눈에 볼 수 있게 멤버 필드를 맨 위에 쓴다. 멤버 함수를 다 써야 그 다음으로 넘어갈 수 있기 때문이다.

C++은 어떻게 쓰든 하늘이 보인다.(?)

 

Explicit 키워드를 모든 생성자에 붙여준다.

 

Namespace

자바에서 패키지와 유사하다. 자바에서 패키지는 클래스의 모임, 집합이다. namespace는 코드를 나눠놓았다. 코드의 영역을 구분해 놓았다. 코드 뭉치들을 특정 영역 안에 넣어 구분 짓는 것이다.

 

메인 함수는 네임스페이스 밖에 있어야 한다.

 

같은 이름의 변수를 두 번 정의할 수 없다. 클래스도 마찬가지이다.

네임스페이스를 통해서 코드를 분리할 수 있다.

중첩해서 쓸 수도 있다.

네임 스페이스를 한 군데에 넣지 않아도 된다. 이름으로 구분짓기 때문이다.

 

이름 지을 때 스네이크 케이스를 이용해서 짓는다.

그리고, 네임 스페이스가 끝나는 지점에는 주석을 달아준다. 네임 스페이스 영역이 어디까지인지 알기 편하도록, 중첩되어 있어도 금방 확인할 수 있도록 한다.

네임스페이스 안에는 들여쓰기를 하지 않는다.

 

using namespace 패턴은 굉장히 나쁜 프랙티스이다.

같은 이름의 함수를 사용하는 namespace가 두 개 있을 때, 두 개 모두 using namespace를 쓰면 중복으로 인해 충돌이 일어난다.

따라서, using (영역 이름)::쓰는 거 로 쓰면 된다.

using theory::foo;

using practice::bar;

foo(); bar();

네임스페이스를 열어버리는 using namespace '' 을 쓰는 것은 자제하자.