게시판 활용 까지만 있던데..

차후에 CSS와 soap연동 까지의 책을 하나 더 파야하낭

eBook Only & DRM-free

[지은이] 강대명
빅데이터와 클라우드 등에 관심이 많은 개발자입니다. 파이널데이터에서 디지털 포렌식을, NHN에서 메일 서비스를 개발하였습니다. 현재는 모든 걸 정리하고 더 나은 미래를 만들기 위해서 필리핀에서 영어를 공부하고 있습니다.

1장. 분산 캐시가 왜 필요할까?
  01. 대규모 트래픽 처리의 성능 이슈
  02. 서비스의 시작, 하나의 DB에서 모두 처리하기
  03. Read가 많을 경우 Read와 Write를 분리하자
  04. Write 증가하면 파티셔닝하자

2장. 분산 캐시를 구현하는 핵심 기술: Consistent Hashing
  01. Consistent Hashing

3장. 분산 캐시의 활용
  01. Memcached
  02. Redis

4장. 분산 캐시 솔루션을 사용할 때 주의할 점
  01. 메모리 사용량에 주의하자
  02. 성능이 갑자기 떨어지면 메모리 스와핑을 의심하자
  03. Memcached와 Redis의 flush는 어떻게 다를까?

5장. Redis를 이용한 간단한 Short URL 서비스 구축하기
  01. Read를 Redis로 대체하자
  02. Short URL 생성 로직도 Redis로 대체하자
  03. Redis의 Sorted Set을 이용한 인기 URL 찾아보기

this-> 를 접두사로 붙이거나 기본 클래스 한정문을 명시적으로 써주는 것으로 해결.

자세한 내용은 책. 말이 너무 길다

아래의 두 템플릿 선언문에 쓰인 class와 typename의 차이점은 무엇일까?

template<class T> class Widget;

templat<typename T> class Widget

이 둘은 차이가 없다. 템플릿의 타입 매개변수를 선언 할 때는

class와 typename의 뜻이 완전히 똑같다. 

하지만 중첩 의존 타입 이름을 식별하는 용도에는 반드시 typename을 사용 한다.

단, 중첩 의존 이름이 기본 클래스 리스트에 있거나 멤버 초기화 리스트 내의 기본 클래스 식별자로 있

는 경우는 예외이다.

template<typename C>                        // typename 쓸수있음(class와 같은 의미)

void f( const C& container,                  // typename 쓰면 안됨

    typename C::iterator iter );         // typename 꼭 써야함.

객체 지향 프로그래밍의 세계를 회전시키는 축은 명시적 인터페이스( explicit interface ) 와

런타임 다형성( runtime polymorphism ) 이다.

클래스 및 템플릿은 모두 인터페이스와 다형성을 지원한다.

클래스의 경우. 인터페이스는 명시적이며 함수의 시그너처를 중심으로 구성되어 있다.

다형성은 프로그램 실행 중에 가상 함수를 통해 나타난다.

템플릿 매개변수의 경우 인터페이스는 암시적이며 유효 표현식에 기반을 두어 구성 된다.

다형성은 컴파일 중에 템플릿 인스턴스화와 함수 오버로딩 모호성 해결을 통해 나타난다.

class AAA

{

public:

void print(){ printf("asd\b"); };

};

class BBB : public AAA

{

public:

int add(int a, int b)

{ int c = a + b;

   return c;

}

};

void main()

{

BBB a;

a.AAA::printf

}

위 처럼 기본클래스의 이름을 명시적으로 쓰라는거

상속의 이미 자체가 is-a 관계다.

기본 클래스에 적용되는 모든 것들이 파생 클래스에 그대로 적용 되어야 한다.

왜냐면 모든 파생 클래스 객체는 기본 클래스 객체의 일종이기 때문이다.

인라인 함수는 작고, 자주 호출되는 함수에 대해서만 하는 것으로 묶어두자

그러면 디버깅, 라이브러리의 바이너리 업그레이드가 용이해 지고, 자칫 생길 수 있는

코드 부풀림 현상이 최소화 되며, 프로그램의 속력이 더 빨라질 수 있다.

인라인은 요청이지 명령이 아니다.

굳이 선언 하지 않아도 컴파일러가 알아서 등록 해주는 것도 있다.

다른 방법이 있다면 캐스팅은 피하라.

구형 스타일의 캐스트를 쓰려거든 C++ 스타일의 캐스트를 선호하라.

분명 객체 지향 법칙은 할 수 있는 만큼 데이터를 캡슐화 하라고 주장하고 있다.

어떤 것을 캡슐화 하면 우선 외부에서 이것을 볼 수 없게 된다.

캡슐화하는 것이 늘어나면 그만큼 밖에서 볼 수 있는 것들이 줄어든다.

밖에서 볼 수 있는 것들이 줄어들면 그것들을 바꿀때 유연성이 커진다.

변경 자체가 영향을 줄 수 있는 범위가 변경된 것을 볼 수 있는 것들로 한정되기 때문이다.

이미 있는 코드를 바꾸더라도 제한된 사용자들밖에 영향을 주지 않는 융통성을 확보 할 수 있는데

이런 것들 때문에 캡슐화에 가치를 두는 것이다.

그 클래스의 private 멤버에 접근 할 수 있는 멤버함수(+프랜드 함수)의 개수가 늘어날수록

캡슐화 정도가 낮아진다고 볼 수 있는 것이다. 비멤버 비프렌드 함수는 private 멤버에

접근 할 수 없기 때문에 그 클래스의 캡슐화 수준은 유지하면서 인터페이스의 유연성을

높일 수 있는 것이다.

비멤버 함수를 쓴다고 해서 꼭 전역 함수를 쓸 필요는 없다. 다른 유틸리티 클래스 같은 곳의

정적 멤버 함수로 만드는 것도 괜찬다. 더 나은 C++ 스타일의 방식은 비멤버 함수로 두되

네임스페이스 안에 두는 것이다.

※ 멤버 함수보다는 비멤버 비프렌드 함수를 자주 쓰도록 합시다. 캡슐화 정보가 높아지고

패키징 유연성도 커지며 기능적인 확장성도 늘어납니다.