class SOME_OBJECT ... // 추상 클래스
// AddChild 멤버함수를 갖고 destructor 에서 Children 을 삭제하는 역할 담당.
// Singleton 일 수 있음.
class CONTAINER : public SOME_OBJECT ...
CONTAINER* container; // 할당되어 있다 치자
class PARENT : public SOME_OBJECT
{
public:
PARENT( SOME_OBJECT* owner )
{
owner->AddChild( this );
}
};
class CHILD : public PARENT
{
using inherited = PARENT; // 이러면 super 처럼 쓸 수 있음
public:
CHILD( SOME_OBJECT* owner ) : PARENT( owner ){} // 자식 클래스들을 만들때 마다 부모로 릴레이
};
**** N 개의 child class 를 추가 개발하면서 container 에 대해 알 필요가 없음
**** 오로지 부모 생성자 초기화 만으로 새로운 클래스 참여 완료.
//////////////////////////////////// 여기까진 프레임웍 개발 타임
여기서부터 가져다 쓰는 시점 ////////////////////////////////////
1. 가져다 쓸때 CHILD 의 다른 프로퍼티를 건드릴 필요 없으면
new CHILD( container );
2. 다른 프로퍼티에 접근해야 할 때
CHILD* child = new CHILD( container );
child->blahblaa...
child->blahblaa...
**** 1. 2 두 케이스 모두 생성자와 container 라는 이름만 접근.
///////////////////////////////////////////////////////////////////////////////////////
아래는 이렇게 구현되어 있지 않을 경우.
1. 가져다 쓸때 CHILD 의 다른 프로퍼티를 건드릴 필요 없으면
container->AddChild( new CHILD );
2. 다른 프로퍼티에 접근해야 할 때
CHILD* child = new CHILD;
child->blahblaa...
child->blahblaa...
**** 1. 2 두 케이스 모두 생성자와 container 라는 이름 외에 AddChild 라는 멤버함수를 기억+사용해야 접근.
두 코드의 기능에 차이가 있냐? No
손품은 후자가 더 팔지? Yes
어느쪽을 선택하든 자유야. 동작도 같아. ㅉㅉ
난 커졌을 때 손 덜가고 기억 덜하는 코드를 택하겠다 이거야.
어려운얘기로너의호기심을자극할수도있어
C++ 알못, OOP 알못들이 또~
패턴이 다르데도 자꾸 이러네. ㅉㅉ. 만약 TApplication이라던가 니가 아는 어떤 표준화된 라이브러리에서 라도 owner->Add 같은 호출을 생성자에서 하는게 있다면 알려줘봐 그럼.
니가 찾아봐.
패턴이 뭐가 다른데. 생성할때 파라메터 안 넘기는거?
저 예제에선 바꿔낄 컨테이너가 없는데 왜 넘김?
PLAYER 가 players 말고 다른 컨테이너에 들어갈 일이 있다면야 파라메터를 추가하겠지. 그럴 일이 없으니 안한거지.
필요하면 필요할 때 추가하면 되는거고, 뭐가 다른데 저거랑?
파라메터는 상관없고. 생성자에서 싱글톤이나 전역변수 컨테리너에 자기 자신(항목)을 목록에 추가하는거. 어떤 방식이든 상관없는데데. 그걸 생성자를 통해서 하는거.
병신아. ㅉㅉ 그래서 니가 저 소스코드 바꿔서 올려봐 니가 옳다고 생각하는 그대로 올려봐라.
저 코드도 수정 못한다고? 그런건 아니겠지? 니가 옳다고 생각하는 방향으로 클래싱 바꿔서 올려봐.
PLAYERS -> { HUMAN, COMPUTER } 상속구조는 바꾸지 말고. 생성방법 바꿔서 올려봐.
그렇게 해서 중복코드 나보다 적나 보자고.
굳이 올릴 필요가 있냐? 생성자 통하지 않기만 하면 되는 것을? 귀찮을때만 가끔 쓰면 좋은걸을 확장성이나 리팩토링 고려해서 짰다면서?
당연 고려 했지. 올려 병신아.
니가 낫다고 생각하는거 올리면 조목 조목 반박해준다.
proxy 로 끝도 없는 개소리 늘어놓고 있어 병신새끼가.
너처럼 짜는게 확정성이나 리팩토링시에 그렇게 좋다면 다른 표준라이브러리도 다 그렇게 짰겠지. 왜 빙빙 돌려가며 짰을까? ㅄ아 ㅋㅋ
빨리 코드 올려. 몇 줄 고친다고 징징거리니
재사용성인정
이기야!!
이거 컨테이너 싱글턴으로 만들고 커링하면 socket.io이랑 같은구조네
흔히 쓰이징~
전역으로 저렇게 할당해 놓고 OOP니 뭐니 하는 거냐 지금..ㅋ 타이핑 수 줄일려면 디파인 해놓고 걍 C써..
전역변수를 도대체 왜 쓰신건가요? UI Control Component처럼 클래스 설계단계부터 필요한 유일한 컨테이너임을 가정한건가요? 아니면 컨테이너정의부분은 컨테이너가 어딘가에 할당되있다는 걸 알려주는 유사코드인가요?
singleton 알못들이 또~
singleton pseudo 코드라고 딴 글에도 적었지만. 귀찮아서 전역으로 적는것.