OOP 개요

OOP 개요

---

[사전지식]

[추상화]: 클래스간의 공통점을 찾아내어 구체화 되어있지 않은 공통의 조상을 만들어 다형성을 보장하도록 하는 것

추상화 하는 공통의 조상은 인터페이스 혹은 추상 클래스로 만든다.

설계도로써 자손이 재정의하거나 사용해야하는 모든 맴버를 정의한다.

 

[구체화]: 추상화된 공통의 조상을 상속하여 구체화 한 자식 class

class 확장의 방법은 상속 및 포함관계가 있다.

 

[다형성]: 공통의 부모 타입 인스턴스로 자손 타입을 참조할수있다. 단, 부모로 부터 상속된 맴버 혹은 Overriding된 맴버만 호출가능

자손 고유의 메서드는 참조 불가

공통조상의 맴버 외 의 자손 고유의 맴버설계는 설계가 잘못된 경우가 많다.

 

[추상클래스 vs 인터페이스]: 자바에서 인터페이스는 다중구현이 가능하고 상속은 1:1 로 제한되어있다.

추상클래스의 장점은 구현체들에게 맞게 다양한 오버라이딩을 요할수있다는 점이다.

추상클래스는 추상클래스를 상속하여 중간 클래스의 역할을 할수있다.

일부 디자인 패턴에서는 다중구현을 이용하기 위해 구체화 단계에서 매번 인터페이스의 메서드들을 재정의 해야하는 코드 중복을 감수하면서도 인터페이스를 사용한다. (ex 관찰자 패턴)

 

1.모듈(Module)

• 소프트웨어 설계에서 기능단위로 분해하고 추상화 되어 재사용 및 공유 가능한 수준으로 만들어진 단위
• 그 자체로 하나의 완전한 기능을 수행할 수 있는 독립된 실체로 본다

• 모듈화: 프로그램을 하나의 기능을 수행하는 독립적인 실체들로 나누어 설계한다.

모듈화가 잘 되면 캡슐화가 잘 되었다고 볼수있다.

 

2.캡슐화

• 데이터와 그 데이터를 처리하는 함수를 하나의 틀에 함께 정의
• 함수 중심에서 데이터 중심으로 설계할수있도록 도움
• 객체의 속성(data fields)과 행위(메서드, methods)를 하나로 묶고
• 실제 구현 내용 일부를 외부에 감추어 은닉한다.

사용자는 제공되는 정보만으로 충분히 객체를 활용할수있다.

즉, 접근제어를 통해 강건성 확립

• 클래스를 통해 우리는 재사용이 가능한 ''모듈(small manageable unit)'' 을 얻게 된다.

 

캡슐화의 원칙

1. private 즉, 외부에 은닉해야하는 데이터는 직접 상호작용하지 않고 접근자를 별도로 생성한다.

class User{
    private int secretData ="암호";

    //접근자로 간접 상호작용
    public int getData(){
        return secretData
    }

    //수정자는 만들지 않는다
}

 

2. 불변 객체를 활용한다.

class User{
    public final int secretData ="암호"; // 직접 상호작용해도 문제 x
}

 

3.관계

 

3-1 객체간 관계

• 객체는 다른 객체와 다양한 관계를 맺으며 사용된다.
• 동적관계이다

실행시간에 변경 가능

• 사용(use-a) 관계와 포함(has-a) 관계로 구분

사용 관계(use-a)

논리적 관계

물리적인 관계와 상관없이 어떤 행위를 위해 다른 객체를 사용하는것

맴버변수로 유지 X

 

포함 관계(has-a)

물리적 관계

한클래스가 다른 클래스를 ''맴버변수로 유지 O'' 하면 무조건 포함관계

부분전체관계 & 연관관계로 나눌수있다.

부분전체관계는 복합관계 & 집합관계로 나눌수있다.

전체가 소멸힐 때 부분도 함께 자동 소멸해야 하면 복합 관계라 하고, 그렇지 않으면 집합 관계라 한다.

복합관계

객체 내부에서 new 생성

집합관계

객체 외부에서 객체를 받아와 생성

연관 관계는 단순 포함

ORM 관계 매핑에 사용

 

단순히 행위를 위해 사용했지만 자주 사용하게 되어 맴버변수로 유지하는 경우가 많다.

이경우 사용관계이면서 포함관계라고 한다.

 

3-2 클래스간 관계

• 정적 관계

코드를 수정해야만 관계를 변경할수있다.

• subclassing & subtyping로 구분

Subclassing 한 클래스의 상태와 행위의 구현을 재사용함

상속

A가 B를 상속하면 A는 모든 B의 맴버를 사용할수있다.

Subtyping 외부 모습만 재사용함

인터페이스

A가 B를 구체화하면 A는 B가 쓰이는 모든곳에 대체될수있다.

 

Subclassing이 항상 Subtyping을 제공하지는 않는다.

A가 B를 상속하더라도 B의 private 맴버는 상속되지 않는다.

그러면 B가쓰이는 모든곳에 A가 대체될수없다. => Subtyping 조건 불만족!!

 

상속 과 구현

• 상속

장점

코드 중복을 제거

공통리모컨으로 사용

자손 고유의 메서드는 공통리모컨으로 사용이 불가함으로 설계를 다시 고민해볼것

특정 부모 메소드가 필요 없을 경우에는 자식에서 빈 메소드로 재정의하기보다는 해당 메소드를 빈 메소드로 재정의한 중간 클래스를 도입

abstract를 활용하여 자식에게 재정의를 강제

단점

너무 강한 결합도 -> 필요없는것도 상속됨 -> 중간클래스를 활용해서 해결가능

IS-A가 성립하더라도 상속자체가 적절하지 않을수있음

• 구체화

상속을 통해 묶을 경우 논리적으로 어색할 수 있는 것들을 interface라는 개념으로 다양한 것들을 논리적으로 묶어 다형성을 활용

• 의문점 해결

public class A extends B implements C

위의 경우 B의 아주 특이한 일부 자손들만 C를 구현한다고 했을때 공통리모컨으로 만약 B를 쓴다면 

B도 C를 구현하고있어야 공통리모컨으로써 B를 원활하게 사용할수있을것인데 이 이유만으로 B가 대부분 자손이사용하지않는 C를 구현하는게 올바른가?

하지만 B가 C를 구현하지 않는다면 C의 메서드를 사용할수 없으니 공통리모컨의 역할을 할수없다. 하지만 공통 리모컨으로 조작하고 싶다.

방법1
이 경우 B를 상속받으며 C를 구현하는 중간클래스를 사용하여 C를 구현하는 B의 일부자손들이 그 중간클래스를 상속받도록한다.

방법2
만약 필요하면 C를 구현하고 있는 객체인지 확인한 후에 C로 타입 변환 후 사용허면 됩니다. if(o instanceof C c) foo(c);

 

의존관계

• 한클래스가 다른 클래스를 사용하고있으면 의존관계가 있다 라고 한다.

• 의존관계는 최소화 될수록 좋다

• 구체 클래스와 의존관계를 맺으면 코드 수정이 필수적이다.

  추상타입에 의존해야한다. = 공통리모컨(부모, abstract부모, interface)로 참조

• 의존관계는 일방향이어야한다.

 

다형성

• 다형성이란 참조 타입의 변수가 가리키는 실제 객체의 클래스에 따라 그것에 맞는 메소드가 호출된다는 것을 의미
• 유연성 증가
• 의존성을 낮출수있음

 

자바만의 OOP 장점

• Object 클래스의 존재, 범용 프로그래밍 및 일관성 유지

equals, clone등 Object 메소드를 사용함 재정의 가능

• interface 개념, 유연한 설계

• 접근제어자 존재 private, protected