[스프링 입문을 위한 자바 객체지향의 원리와 이해] 3장 : 자바와 객체 지향

객체지향은 인간 지향이다

객체 지향의 큰 그림

• 세상의 모든 것은 "객체"다.
• 각각의 고유하다.
• 사물은 속성을 갖는다.
• 사물은 행위를 한다.

우리 인간은 사물을 "분류"를 통해 이해하고 인지한다.

클래스 : 객체

사람은 나이, 몸무게를 가지며 "먹거나, 자거나, 우는 등에 행동"을 하는 물체를 뜻한다. (개념에 따른 분류)

 

우리가 실제 사물을 인지하고 사고하는 방식대로 객체 단위의 프로그래밍이 객체 지향에서 가능하다.

 

객체 지향의 4대 특성 - 캡! 상추다 

• 캡슐화 : 정보은닉
• 상속 : 재사용
• 추상화 : 모델링
• 다형성 : 사용편의

클래스 vs. 객체 = 붕어빵틀 vs. 붕어빵 ???

붕어빵틀 붕어빵 = new 붕어빵틀(); //???

붕어빵틀을 새로운 만든다고 "붕어빵"이 될순 없다

-> 붕어빵틀은 그저 붕어빵을 만드는 팩터리일 뿐이다.

클래스와 객체의 구분 방법

주어진 단어에 나이를 물어보자. 만약 대답할 수 있다면 객체이고 대답할 수 없다면 클래스일 것이다.

사람 -> 클래스, 김연아 -> 객체

클래스는 분류에 대한 개념!
객체는 실체화한 것!

추상화: 모델링

"객체 지향의 추상화는 곧 모델링이다"

추상화란 구체적인 것을 분해해서 관찰자가 관심 있는 특성만 가지고 재조합하는 것이다.

(세부사항은 버리고 중요하고 공통적인 것만 취해 내가 관심있는 것에 집중하는 것)

 

• 객체 : 세상에 존재하는 유일무이한 사물
• 클래스 : 같은 속성과 기능을 가진 객체를 총칭하는 개념

우리는 객체를 먼저 인식하고 그 객체가 가진 특성에 따라 분류를 통해 클래스를 인식하게 된다.

하지만 사물의 창조주는 "아담"과 "이브"라는 객체를 만들기 전에 클래스라는 개념을 먼저 만들었을 것이다.

 

우리도 객체 지향에서는 해당 애플리케이션의 창조주가 된다.

애플리케이션 개발자는 클래스를 설계하기 위해 필요한 물체의 공통된 특성을 파악한다.

 

개발자가 "사람 클래스"를 만든다면 "먹다, 자다, 일하다, 울다, 시력, 몸무게, 나이 등" 여러 공통된 특성을 찾게 된다.

 

하지만  과연 "사람"의 모든 특성을 나열할 필요가 있을까??

 

개발자가 필요한 "사람"은 Context(애플리케이션 경계)에 따라 달라질 수 있다.

 

병원 애플리케이션 -> 시력, 몸무게 정보나 접수하다. 등의 기능이 필요하다.

은행 애플리케이션 - > 시력, 몸무게 정보는 필요없고 나이, 연봉이나 이체하다. 대출하다. 등의 기능이 필요하다.

 

결국, IT 관점의

추상화란 구체적인 것을 분해해서 관심 영역(애플리케이션 경계)에 있는 특성만 가지고 재조합하는 것을 말한다. (모델링)

-> 자바는 이러한 객체 지향의 추상화를 "class 키워드"를 통해 지원하고 있다.

 

클래스 멤버 - 객체 멤버

클래스 변수는 해당 클래스의 모든 객체가 같은 값을 가질 때 사용하는 것이 기본이다.

클래스 메서드는 객체들의 존재 여부에 관계없이 쓸 수 있는 메서드이다. ex) Math와 같은 유틸리티성 메서드

상속: 재사용 + 확장

상속은 계층적인 개념이 아닌 "재사용과 확장"으로 이해하는 것이 맞다!

부모-자식 간의 관계 (X)

-> 동물은 포유류의 부모가 될 수 없다. 동물을 좀 더 세분화해서 포유류가 나올 수 있다.

 

**상속은 계층도가 아닌 분류도이다**

부모클래스 - 자식클래스 (x)

슈퍼클래스 - 서브클래스 (o)

 

 

추상화(일반화) vs 구체화(특수화)

상위 클래스로 갈수록 추상화/일반화가 되고 하위 클래스로 갈수록 구체화/특수화가 진행된다.

 

상속관계에서 만족해야만 하는 문장

• 하위 클래스는 상위 클래스이다. (리스코프 치환 법칙)

영희는 아빠가 될 수 없다. (일반화 불가)

펭귄은 동물의 역할을 수행할 수 있다. (일반화 가능)

 

• 'is a' 보단 'a kind of'

펭귄은 한마리의 조류이다 보단 펭귄은 조류의 한 종류이다.

상속의 강력함

• 상속을 통해 최상위 클래스 Object의 특성을 물려받아 toString() 메서드를 모든 서브클래스에서 사용가능하다.
• 구체화된 객체들을 하나의 일반화된 개념으로 사용할 수 있다.

자바는 다중 상속의 다이아몬드 문제로 인해 다중상속을 버리고 인터페이스를 도입했다.

 

상속과 인터페이스

상속과 인터페이스

인터페이스는 'be able to'와 같이 "무엇을 할 수 있는" 형태로 만드는 것이 좋다.

• 자바 API 예시
  • Comparable 인터페이스 : 비교할 수 있는
  • Runnable 인터페이스 : 실행할 수 있는

인터페이스는 클래스가 '무엇을 할 수 있다'라는 기능을 구현하도록 "강제"하게 된다.

 

• 퀴즈
  • 상위 클래스는 하위 클래스에게 물려줄 특성이 많을수록 좋을까?
  • 인터페이스는 구현을 강제할 메서드가 많을수록 좋을까?

리스코프 치환 원칙에 의해 상위 클래스가 풍성할수록 좋다.

인터페이스 분할 원칙에 의해 인터페이스 메서드는 적을수록 좋다. (자신의 책임이 아닌 것을 맡을 수 있으므로..)

 

다형성: 사용편의성

객체지향에서 다형성이라고 하면 "오버라이딩"과 "오버로딩"이라고 할 수 있다.

-> 하지만 "오버로딩"이 다형성인지에 대해서는 이견이 있다.

 

오버라이딩 : 같은 메서드 이름, 같은 인자 목록으로 상위 클래스의 메서드를 재정의

오버로딩 : 같은 메서드 이름, 다른 인자 목록으로 다수의 메서드를 중복 정의

 

Animal pingu = new Penguin();

위 코드에서 pingu의 showName() 메서드를 실행하면 Animal 객체에 의해 정의된 메서드가 아니라 Penguin 객체에 의해 재정의된 showName()메서드가 실행됨을 기억하자.

 

-> 상위 클래스 타입의 객체 참조 변수를 사용하더라도 하위 클래스에서 오버라이딩한 메서드가 호출된다!!

상위 클래스 참조 변수로 하위 클래스가 오버라이딩한 메서드를 사용할 수 있다.

 

다형성은 개발자가 프로그램을 작성할 때 사용편의성을 준다.

 

캡슐화: 정보 은닉

정보은닉하면 생각나는 접근제어자 -> private, pretected, public

 

접근 제어자

• 상속을 받지 않았다면 객체 멤버는 객체를 생성한 후 참조 변수를 통해 접근할 것
• 정적 멤버는 클래스명.정적멤버 형식으로만 접근하는 것을 권장.

참조 변수의 복사

기본 자료형 변수 복사시 에는 "Call by Value"에 의해 복사되어 두 개의 변수가 서로에게 영향을 전혀 주지 않는다.

 

참조 자료형 변수는 값을 주소, 즉 포인터로 판단한다.

결국, 두 자료형 모두 복사시에 자신이 가지고 있는 값을 그대로 복사해서 넘겨준다. 그게 값이냐 주소값이냐의 차이일 뿐이다.