객체지향에 관련해서, 가볍게 내용을 정리하였습니다. 참고서적 : 스프링 입문을 위한, 자바 객체 지향의 원리와 이해 김종민 지음 객체지향. 말은 참 어려운데. 프로그래밍 하면서 사람이 인식하는 사물 또는 실체를 하나하나 조합해서 프로그래밍 하자는 패러다임입니다. 쉽게, 객체를 가지고 놀자 이겁니다. 객체지향언어에서는 클래스(Class) 객체(Object)가 존재합니다. 클래스는 추상화 및 분류 객체는 실제를 의미합니다. 예) 사람클래스 -> 원빈 객체 / 동물 클래스 -> 고양이 객체 4대 특징 - 캡슐화 - 상속 - 추상화 - 다형성 객체지향 개념을 완벽히 이해하려면. 많이 공부해야 할거같습니다..ㅠㅠ

3.  모든 신기술은 갑자기 하늘에서 뚝 떨어지지 않았다.
이전 기술의 어깨를 디딤돌 삼아 그 위에 이전 기술이 제시한 철학과 기법을 정반합의 논리로 정제하고, 이
전기술을 거름 삼아 새로운 철학과 기법을 더해 나가는 것이다.
 신기술을 학습하려면, 이전기술을 알아야 하는건가?(Spring / MSA 등)
의미와 철학을 살펴보기만 하면 된다.

4. 기계어 – 0과 1의 행진 / 너무나 비인간적인 언어
컴퓨터는 0과 1밖에는 이해하지 못한다. 지금도 마찬가지임. -> 컴퓨터는 바보다. 왜? 0과 1밖에 모르니까.
그래서, 우리가 컴퓨터를 이해하려면 눈높이를 낮추는 수밖에 없다.(사람은 10진법 기본 + 여러 언어도 구사한다)
그런데, 왜 0과 1밖에 모르는 컴퓨터에 의존하는 삶을 살고 있을까?
-> 컴퓨터가 0과 1 (2진법)밖에 모르는 바보지만, 대단히 빠르고 성실하며 정확하기 때문이다.
기계어는 기계가 이해하는 유일한 언어로, 2진 숫자인 0과 1로만 표현된다.
저급 언어 (Low-Level Language)
- 기계 중심의 언어
- 실행 속도가 빠름
- 상이한 기계마다 다른 코드를 가진다
기계어 (Machine Language) : 컴퓨터가 직접 이해할 수 있는 언어, 0과 1의 2진수 형태로 표현되며 수행시간이 빠름. 전문적인 지식
이 없으면 프로그램 작성 및 이해가 어렵다, 기종마다 기계어가 다르므로 언어의 호환성이 없음. 프로그램 유지보수가 어렵다.

5. 어셈블리어 – 0과 1의 행진을 벗어나 인간 지향으로 / 기계어 니모닉
기계어는 컴퓨터가 이해하는 유일한 언어지만, 인간이 눈높이를 그 수준까지 낮추기에는 너무 낮다.(어렵다)
그래서, 이 수준을 낮추는걸 조금 줄여보기 위해서 기계어를 일상용어로 표현하고 이걸 기계가 알 수 있는 기계어로 번
역하게 만드는 아이디어가 나오면서 니모닉(Mnemonic)과 기계어의 1:1 매칭 코드표를 만든 것이다.
어셈블리(assembly)는 기계어와 일대일 대응이 되는 컴퓨터 프로그래밍의 저급 언어이다.
그런데, CPU마다 기계어가 다르기 때문에 CPU별로 각자의 어셈블리도 달랐다.(애드삭은 PLUS, 유니박은 ADD)
어셈블리를 기계어로 번역해 주는 소프트웨어를 어셈블러(assembler)라고 한다.

6. C 언어 – 강력한 이식성 / One Source Multi Object Use Anywhere
처음 C가 나왔을 때, 개발자들은 감동을 했을까? 대답은 Yes다.
-> 어셈블리는 같은 일을 하는 소스 파일을 각 기계의 종류만큼 만들어야 했다.
그런데, C언어의 등장으로 이제는 소스파일을 단 하나만 생성하면 된다. 그리고 그 소스파일을 각 기계에 맞는 컴파일러
로 컴파일만 하면 각 기계에 맞는 목적 파일이 만들어 진다. -> One Source Multi Object Use Anywhere
그리고, C언어가 프로그래밍 방법에 있어서 새로운 패러다임을 제시했는데 바로 함수로 대표되는 구조적 프로그래밍이
다.

7. C++ – 강력한 이식성 / One Source Multi Object Use Anywhere / 객체지향 개념을 도입
C++은 C와 똑같지만, 객체지향 개념을 도입하면서 역사에 한 획을 그은 언어다.
C언어는 절차지향 + 구조적 프로그래밍이라는 패러다임을 제시했다.
C++은 객체지향 프로그래밍이라는 패러다임을 제시 했으나, C++은 C의 패러다임에서 객체지향의 개념을 포함(C언어에
대한 특성과 효율성을 포함시키고 싶어했음)했기 때문에 C++에서 C언어 방식으로도 코딩이 가능해서 완전한 객체지향
언어는 아니다라는 이야기를 듣게 된다.
Java – 진정한 객체 지향 언어 / Write Once Use Anywhere = Write Once, Run Anywhere(WORA)
Write Once, Run Everywhere(WORE)
자바가 진정한 객체 지향 언어?
-> C++은 진정한 객체 지향 언어가 아니라는 뜻이다. 왜? C++도 객체 지향 개념에 충실한 언어이긴 하지만, C++은 객
체 없는 프로그래밍도 가능했다는 점이다.
객체 지향 언어의 중심에는 클래스(Class)가 있다.
자바에서는 클래스(Class)를 떠나 존재할 수 있는 것은 아무것도 없다.
main() 메서드 또한 C++은 별개로 존재하며, 자바에서는 클래스 외부가 아닌 내부에 존재한다.
Java는 JVM(Java Virtual Machine)을 통해, Write Once Use Anywhere를 실천했다.

9. 객체 지향은 인간 지향이다.
프로그래밍 언어의 발전사를 보면 개발자를 더욱 편하고 이롭게 하기 위한 과정임을 살펴볼 수 있었다.
-> Low Level 에서 High Level
그러나, 절차적/구조적 프로그래밍에서도 인간이 기계를 이해하려는 노력에서 크게 벗어나지 못했다.
그래서 이렇게 기계에 종속적인 개발을 피하고, 현실세계 처럼 프로그래밍할 수는 없을까라는 고민에서 객체 지향의 개
념이 탄생했다.
그래서, 결론은 객체 지향은 0과 1로 대변되는 기계에 맞춰 사고하던 방식을 버리고 현실세계를 인지하는 방식으로 프로
그램을 만들자는 것이다. -> 현실세계를 인지해서 만들기 때문에, 객체 지향은 직관적이다.
- 세상에 존재하는 모든 것은 사물. 즉 객체(Object)다.
- 각각의 사물은 고유하다.
- 사물은 속성을 갖는다.
- 사물을 행위를 한다.
-> 그리고, 사물은 하나하나 이해하기 보다는 사물을 분류(Class)해서 이해하는 것이 인간의 인지법이다.
- 김종민(Object), 최배달(Object) 이라고 하는 존재는 사람이라는 분류(Class)에 속한다. 그리고 최배달(Object)은 나이, 키 속성
(property)을 가지며, 먹다, 자다 등의 행위(method)를 한다.

10. 객체 지향의 4대 특성 – 캡!상추다
캡슐화 - 정보은닉
상속 – 재사용 / 확장
추상화 - 모델링
다형성 – 사용 편의(여러 형태로 사용 가능)
캡슐화
Method와 Property를 포장하고 외부에 노출할 것과 감출 것을 결정하는 것. 외부에 노출되는 모든 것을 Interface라고
할 수 있다. 자바에서는 접근 제어자를 통해서, 숨길지 공개할지 결정.(public, private, protected, default)
다형성
여러 형태를 가질 수 있는 능력 + 상속을 통해, 기능을 확장하거나 변경하는 것
오버라이딩(overriding) / 오버로딩(overloading) / 상위클래스와 하위클래스 / 인터페이스와 구현클래스
오버라이딩 : 상위클래스의 메서드를 재정의
오버로딩 : 같은메서드 이름, 다른 인자 목록으로 다수의 메서드를 중복 정의
추상화(모델링)
객체 지향에서 추상화라는 개념은 공통된 속성과 행위를 추출하는 것을 의미한다. -> 모델링
클래스 : 객체 -> 사람 : 김연아 / 개 : 장모치와와
객체는 유일무이한 사물 또는 명사를 의미하며, 클래스는 같은 특성을 지닌 여러 객체를 총칭하는 집합의 개념 또는 분
류의 개념
여기서, 한걸음 더 전진하면 어플리케이션 경계다. 어떤 어플리케이션을 만들지? / 내가 만들고자 하는게 어디에 사용?
그래서, 추상화를 다시 정리해보면. 공통된 속성과 행위를 추출하는 것을 의미 + 관심영역에 대한 또는 필요한 것을 추출

11. 객체 지향의 4대 특성 – 캡!상추다
캡슐화 - 정보은닉
상속 – 재사용 / 확장
추상화 - 모델링
다형성 – 사용 편의(여러 형태로 사용 가능)
상속(재사용 + 확장)
상속이라고 하면 어떤 느낌이 오는가 ?
우리가 일반적으로 알고 있는 상속의 개념도 인
데, 객체 지향의 상속은 이런 개념이 아니다.
오른쪽의 그림처럼, 재사용과 확장으로 이해하
는 것이 올바르다.(분류도)
상속에서 반드시 is a 문장을 만족해야 한다.
-> 고래는 포유류다. -> 포유류는 동물 이다.
-> 하위 클래스는 상위 클래스다.
위의 말은 객체지향설계 5원칙 가운데 LSP(리
스코프 치환 원칙)을 나타내는 말이다.

12. 클래스 VS 객체
보통 서적에서 클래스와 객체의 관계를 붕어빵틀과 붕어빵이라고 많이들 표현을 한다.
객체(Object) : 세상에 존재하는 유일무이한 사물 또는 명사
클래스(Class) : 분류, 집합, 같은 속성과 기능을 가진 객체를 총칭하는 개념
클래스를 이용해 Object를 만들었다는 것을 강조할 때는 클래스의 인스턴스(Instance)라는 표현을 사용한다.
객체(Object) = 클래스(Class)의 인스턴스(Instance)
인스턴스(Instance)는 new 키워드를 통해 생성 및 메모리 영역에 할당된다.(Heap 영역)
클래스를 객체의 설계도라고 설명하는 말은 바로 이런 과정에서 나왔다고 보면 된다.
붕어빵틀과 붕어빵도 클래스와 객체의 이런 일면만 설명하는 용어인데, 클래스와 객체의 전부를 표현하는 말로 착각하
면 안된다.
클래스 객체명 = new 클래스();
-> 붕어빵틀 붕어빵 = new 붕어빵틀(); …? -> 둘다 실체임.. 분류의 개념이 아니다.(분류와 실체의 관계를 생각해보자)
사람은 클래스인가? 객체인가?
김연아는 클래스인가? 객체인가?
동물은 클래스인가? 객체인가?
개는 클래스인가? 객체인가?
클래스는 분류 또는 집합에 개념이지 실체가 아니다. 객체는 실체다.
클래스 : 객체 -> 사람 : 김연아

13. - SOLID ?
• 객체 지향 설계(OOD)의 정수라고 할 수 있는 5원칙이 있는데, 이를 SOLID라고 한다.
• SOLID는 로버트 C. 마틴이 2000년대 초반 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙으로 제시한 것을
• 마이클 페더스가 두문자어로 소개한 것이다.
• SOLID는 아래 5가지 원칙의 앞 머리 알파벳을 따서 부르는 이름이다.
• SRP(Single Responsibility Principle) : 단일 책임 원칙
• OCP(Open Close Principle) : 개방 폐쇄 원칙
• LSP(Liskov Subsituation Principle) : 리스코프 치환 원칙
• ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
• DIP(Dependency Inversion Principle) : 의존 역전 원칙
• 이러한 개념들도 하늘에서 뚝 떨어진 것이 아니라, 응집도는 높이고 결합도는 낮추려는
• 고전 원칙을 객체 지향의 관점에서 재정립 한 것이라고 할 수 있다.
• SOLID라는 개념이 등장한 이유는 설계의 품질을 높이기 위함이라고 생각하면 된다.
설계의 품질 - Quality of Design
잘 설계한 시스템은 이해하기 쉽고, 바꾸기 쉽고, 재사용하기 쉽습니다. 개발하는데 특별히 어렵지도 않고, 단순하고
간결하며 경제적입니다.

14. - SRP(Single Responsibility Principle) : 단일 책임 원칙
남자라는 하나의 클래스가, 역할과 책임에 따라 쪼개진
것을 볼 수 있다. 그리고 역할과 클래스명도 딱 떨어지
니 이해하기도 좋다.(가독성 향상 + 유지보수 용이)
남자 클래스에 의존하는 다양한 클래스가 있다고 생각하자.
이런 경우 객체 지향의 세계에서는 나쁜설계 냄새가 난다고 한
다.
만약, 여자친구가 헤어졌다면. 남자친구 클래스에 있는 키스하
기와 기념일 챙기기는 필요없는 행위가 될 것이다.
이런 경우에 역할(책임)을 분리하라는 것이 단일 책임 원칙이
다.(어떤 변화에 의해 클래스가 변경해야 하는 이유는 오직 하
나뿐이어야 함.)

15. - OCP(Open Close Principle) : 개방 폐쇄 원칙
확장에는 열려 있고, 변경에는 닫혀 있어야 한다는 원리를 말한다.(추상화와 다형성을 통해 가능케 한다)
(요구사항 또는 추가사항이 발생하더라도, 기존 구성요소에는 수정이 일어나지 않아야 한다는 의미이다.)
마티즈는 창문수동 / 기어수동 이라는 기능이 있다. 그런데, 운전자가 나중에 쏘나타로 바꾸었다.(변경 발생)
쏘나타는 자동개방 / 자동조작 이라는 기능으로 변했다. 그럼 운전자는 운전습관을 바꾸어야 한다.
-> 방법에 영향이 생김.
이걸 해결하기 위해서 직접 의존적으로 만드는게 아니라, 상위 클래스 또는 인터페이스를 중간에 둠으로써 다양한 자동
차가 생긴다고 해도 객체 지향 세계의 운전자는 운전습관에 영향을 받지 않게 된다.
다양한 자동차가 생긴다고 하는 것은 자동차 입장에서는 자신의 확
장에는 개방돼 이는 것이고, 운전자 입장에서는 주변의 변화에 폐쇄
돼 있는 것이다.

16. - LSP(Liskov Subsituation Principle) : 리스코프 치환 원칙
서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다는 원칙.(서로 호환이 되어야 한다는 의미)
호환이 되니, 교체를 해도 프로그램은 정상적으로 동작을 해야 한다. 서로 호환을 하기 위해선, 하위타입은 상위타입의
규칙을 지켜야한다.(상위 클래스 또는 인터페이스의 명세를 따라야한다. 이걸 어기면 리스코프 치환 원칙을 어긴거다)
하위에 존재하는 것들이 상위에 있는 것들의 역할을 하는 데 전혀 문제가 없다.
이것을 잘 생각하면, 객체 지향의 상속이라는 특성을 올바르게 활용하면 자연스럽게 얻는 것이 리스코프 치환
이라고 생각을 할 수도 있다.(is a / is able to 관계를 잘 구성하면 된다.)
하위 클래스의 인스턴스는 상위형 객체 참조 변수에 대입해 상위 클래스의 인스턴스 역할을 하는 데 문제가 없
어야 한다.

17. - ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
클라이언트가 사용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다. 아주 쉽게 설명하면,
자신과 관련없는 메서드들이랑 관계 가지지 말라는 거다.
MacPro2015 클래스가 touch()를 사용하
지 않으나, 불필요한 의존관계가 있다. 인
터페이스의 분리원칙을 적용하면 다음과
같다.(다음 슬라이드)
예제 출처 :
http://wonwoo.ml/index.php/post/1675

18. - ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
클라이언트가 사용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다. 아주 쉽게 설명하면,
자신과 관련없는 메서드들이랑 관계 가지지 말라는 거다.
인터페이스를 분리해서, 사용하는 메서드
만 구현을 해주면 된다.(인터페이스의 단
일책임을 강조)

19. - DIP(Dependency Inversion Principle) : 의존 역전 원칙
고차원 모듈은 저차원 모듈에 의존하면 안된다. ..? 쉽게 말하면 자주 변경되는 무언가에 의존하지 마라 이다. 왜? 그만큼
변경이 일어나면 고차원 모듈은 계속 저차원 모듈로 인해 수정하고 변경해줘야함.
자동차 Class가 스노우타이어 Class에 의존하고 있다.
타이어는 계절마다 바뀔수 있다.
중간에, 추상화된 인터페이스를 둬서 자동차 Class가 타이어가 변경이 되어도 영향을 받지 않게 구성했
다.(의존성이 타이어 인터페이스로 역전. 추상화 된 타이어 인터페이스만 의존.)
자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것
의 변화에 영향 받지 않게 하는 것이 의존 역전 원칙이다.
스노우타이어는 타이어를 의존. 만약 요구사항이 변경되어 돌타이어가 생기면 돌타이어 클래스를 만든
후에, 타이어 인터페이스 변수에 변경해서 넣어주기만 하면 된다.
참고로 DI는 DIP를 구현한 기법 중 하나이다.