06/20 TIL (OO적 상호작용~ static, 싱글턴, 내포클래스)

 - 행동을 하기 위해서 개체 자체를 넘긴다.

 : 스프레이 안 쪽에 스프레이 로직만 들어가기 때문에 좀 더 개체 지향적이게 된다.

 : 복잡한 로직도 클래스 안에 숨길 수 있게 된다.

 

 - 개체 : 생물체 + 물체 

 : 물체에게도 주체성이 있게 됨.

 

 - 유연성 떨어진다 : 재활용성이 떨어졌다.

 : 재활용성을 높이면 유연성도 올라간다.

 

 - 사람의 사고방식

: 위에서 아래로 가 가장 자연스럽다 (파일을 너무 많이 점프하면 힘들어진다.)

 

 - 코드 유연성은 양날의 검 

 : 유연성 높 -> 성능 낮, 가독성 낮, 재사용성 높

 : 유연성 낮 -> 성능 높, 가독성 높, 재사용성 낮

 

 - 안 유연해도 괜찮아! 

 : 절대반지는 없음, 유연성 필요는 회사마다 다름

 

 - 필요에 따라 유연성을 유연하게 조정할 것

 

 - 기본기의 중요성

 : 읽기 명확한 코드 만들기

 : 실수 저지르기 어려운 코드 만들기

 : 문제를 해결하는 코드 만들기 (유연성보다는 일단 해결 -> 유연성으로 변경)

 : 문제가 생기면 디버깅 하기

 

 - 간단하게 만들기

 : 미리 규격을 정한다 ->용량을 정확히 몰라도 됨.

 : 책임을 상위 집합으로 전가 -> 하위에서 왔다 갔다 하지 않아도 된다.

 

 - static 필요성

 : 모든 것이 개체 속에 있을 때의 불편함

 : 개체 단위가 아니라 그 상위의 클래스 단위에서 뭔가 하고 싶을 때

 

 - 정적 멤버 함수의 소유주

 : 개체가 아니라 클래스 소속이다 (= 클래스가 소유주다)

 

 - static의 생성자

 : 개체 생성자 만들지 못하는 것 아님

 

 - static을 new로 만들어도 static method가 호출 가능한 이유

 : 여러 개를 만들어도 static은 클래스에 속한 1개라서 접근 가능하므로 허용

 : 반대의 경우는 컴파일이 아예 안 된다.

 

 - static 생성자가 굳이 만들 필요가 없는 경우

 : 생성자를 private으로 만들어 버리면 된다.

 : 무시하면 컴파일 오류

 

 - static 멤버 변수

 : 클래스 통틀어서 뭔가 멤버 변수가 필요할 것 같은 상황에서 사용

 

 - static 메서드

 : static 멤버 변수 컨트롤 할 때 좋은 위치 -> 생성자

 

 - static에 대한 비판

 : 그룹 1 모든 것은 개체여야 한다 -> 개체 소속이 아니기 때문에 안 좋다고 생각하는 사람들이 있음

 : 그룹 2 타 언어 진영 -> low level language가 아닌 언어가 static을 챙겨야 하게 된 것은 잘 생각한 것이 아니다.

 : static 자체가 OO의 개념과 먼 것은 사실 -> 그치만 OO의 개념과 멀다고 잘못된 방법은 아니다.

 

 - 디자인 패턴

 : 인간은 최고의 패턴 인식 기계

 : 인간 문제 해결 과정 : 새로운 문제를 접함 -> 과거의 비슷한 문제를 찾음 -> 해결 방법을 새 문제에 적용

 : 곧바로 적용할 수 없는 참고 가이드를 '패턴'이라 부를 수 없다.

 

 - Singleton 패턴

 : 어떤 클래스에서 만들 수 있는 인스턴스 수를 하나로 제한하는 패턴

 : 프로그램 실행 중에 개체는 최대 하나 (ex. ) configuartion file, file system)

 : singleton static private 멤버 변수 생성 && getInstance() 로 가져 옴

 

 - Singleton vs static (차이점)

 : static으로는 못하지만 singleton으로는 가능한 일 (다형성 사용 가능)

 : multiton 패턴으로 변경 n개의 instance를 제한하는 패턴이 가능

 : 개체 생성 시점 제어 가능하다.

 

 - 개체 생성 시기

 : 처음으로 getInstance() 메서드가 호출될 때

 : 여러 군데에서 getInstance() 메서드를 동시에 호출 할 때 (순서가 중요해 질 때가 있음)

 

 - Singleton 초기화 순서 보장

 : 프로그램 시작 시 여러 싱글턴의 getInstance() 순서대로 호출하면서 호출 순서를 맞춰야 한다.

 

 - Singleton 생성 시 인자가 필요한 경우의 해결 (다른 곳에서 인자의 주입 개념이 어려워 짐)

 : 자신의 타입을 멤버 변수로!

 : 프로그램 실행 시에는 createInstance() 로 설정

 : getInstance()에는 인자를 넣지 않아도 괜찮게 됨 (createInstance 가 먼저 호출됐다는 가정이 있어야 작동)

 : 프로그램 종료 시에 직접 시스템 리소스를 해제해야 하는 경우가 있다면 deleteInstance()를 반드시 호출해 줘야 함. 

 : Singleton을 쓰지 않을 수도 있지만 쓰지 않고 static을 써서 코드가 더 복잡해진다면 굳이 static을 고집할 이유가 없다.

 

 - 내포 클래스

 : 클래스 안에 다른 클래스가 들어가 있는 모습

 : 비정적 내포 클래스(내부 클래스라고 부름), 정적 내포 클래스 로 나뉨

 : 바깥 클래스의 private 멤버에 접근 가능 (바깥 클래스는 내포 클래스의 private 접근 불가)

 

 - 내포 클래스 바깥 클래스의 멤버에 바로 접근 가능다른 

 : private 멤버라도 접근이 가능

 : 다른 바깥 클래스 개체를 메서드의 매개변수로 받아도 마찬가지로 private 멤버에 접근 가능

 : 강한 캡슐화 (패키지 접근 보다)

 : 내부 클래스와 외부 클래스가 대응하고 있다는 연결점을 만들어 주어야 함(A.new B());

 

 - 정적 내포 클래스

 : static 내부 클래스가 여전히 바깥 클래스의 private 멤버에 접근 가능하지만 A 클래스를 선언 해 주어야 함

 : static 클래스라는 의미가 아님

 : 바깥 클래스의 레퍼런스를 받지 않겠다는 뜻임 (바로 위에 있는 것을 자동 적용 안될 것이다)

 : A a 로 선언 & 할당하는 과정이 필요

 : A.new B() 가 아니고 new A.B(a);가 됨

 : 바깥 클래스의 static은 접근이 가능 (왜냐면 클래스 아래에 있기 때문)