프레임워크를 위한 JAVA - OOP

 

OOP 이야기

1. 객체지향 프로그래밍

 

Java가 객체지향 언어이긴 하지만 Java로 개발한다고 모두 객체지향인 것은 아니다.

 

객체지향 프로그래밍이란?

 

프로그램을 객체로 구성하는 것

 

🚀 등장 배경: 프로그램이 거대화하면서 등장
💡 아이디어: 어떻게 큰 프로그램을 만들 것인가? (더 효율적이고 관리하기 좋게)
✅ 해결책: 작게 나눠서 만든 후 합치자

프로그램의 동작을 객체들에게 나눠서 수행하자.

 

객체란 무엇일까?

 

👆 개념적 용어: 객체
👆 기술적 용어: class, instance

 

객체란?

- 큰 프로그램의 구성을 나눈 것

- 기능의 일부를 위임받은 것 (기능의 일부를 수행해야 한다.)

- 작은 기능을 수행한다.

 

객체의 특징

객체와 객체는 서로 협력을 해야 한다.

🤔이유: 함께 큰 프로그램을 만들어야 하기 때문이다.

 

객체지향 프로그래밍의 핵심

 

객체지향 프로그래밍을 잘하는 방법

일을 잘게 쪼개서 객체에게 위임하고, 서로 협력하게 만드는 것.

=> 하나의 커다란 객체 안에 모든 로직을 넣는 것은 절차지향 프로그래밍과 같다.(지양하기!)

 

객체지향 프로그래밍의 핵심

객체는 특정한 임무와 기능을 가지고 해당 일을 해야 하는 책임을 갖는다. 

따라서 책임을 다하도록 객체를 구성한다.

 

객체의 업무를 잘게 쪼개되, 비슷한 업무들은 특정 객체가 수행하도록 일을 분야별로 쪼갠 후 객체에게 잘 위임한다.

쪼개진 객체들이 잘 협력할 수 있도록 프로그램을 구성하는 것. 

 

객체의 구분

 

수많은 객체를 만들게 되므로 이를 서로 구분해야 한다.

 

type(형)으로 구분하기

String객체 생성

 

타입 만들기 (class 만들기)

 

package com.programmers.java;

class MyClass extends Object implements Runnable {
    // field area
    private int a = 0;

    // method area
    public void run() {
        a += 1;
    }

    MyClass mc = new MyClass();
}

MyClass라고 하는 타입을 만들었다. (클래스 타입)

타입의 변수에 해당 타입으로 생성된 instance를 생성 후 대입한다.

---

2. 객체지향의 특성

 

캡슐화

 

👆 완성도가 있다.

기능을 수행하는 단위로써 완전함을 갖는다. (다른 객체와의 의존성을 낮춘다)

 

👆정보가 은닉되어 있다.

밖에서 객체 내의 정보에 접근하지 못하게 한다.

 

✅ 결론

객체는 스스로 동작할 수 있는 환경을 갖고 있어야 한다.

외부에 의존하거나, 외부의 침략을 제한해야 한다.

 

Child는 Parent의 Blood에 직접 접근할 수 없다. (X)

Child는 Parent의 Hair에는 직접 접근할 수 있다. (O)

 

Childe가 Parent의 Blood에 접근하기 위해서는 getBlood()라는 함수를 통해 접근해야 한다.

 

class Parent {
    private Blood blood;
    protected Hair hair;

    Blood getBlood() {
        return Blood;
    }
}

class Child extends Parent {
    void run() {
        this.hair; // (O)
        this.blood; // (X)
        this.getBlood(); // (O)
    }
}

=> 접근 지정자를 통해 캡슐화를 조절한다.

 

⭐ 접근 지정자

- private : 객체 소유 (외부에서 접근 불가능)
- protected : 상속된 객체에서도 접근 가능
- default(friendly) : 같은 패키지 내에서 접근 가능 (패키지 가시성)
- public : 모두 다 접근 가능 (public class는 한 파일에 한 개)

범위: private < protected < default < public

 

상속

 

💡 상속해준다: 상위, 부모, super, 추상
💡 상속받는다: 하위, 자식, this, 구체

 

상속의 오해: 공통된 기능을 여러 객체에게 전달하고 싶을 때 사용한다.

올바른 상속 관계: 추상과 구체 (ex. 원자 > 물질 > 생물 > 동물 > 포유류 > 사람 > 남자 > 짱구)

 

추상화

 

💡추상체: 추상화된 객체
💡구상체: 구체적인 객체

추상체와 구상체의 관계는 상대적이다.

ex)

사람 > 남자의  관계:사람이 추상체, 남자가 구상체 

남자 > 짱구와의 관계: 남자가 추상체, 짱구가 구상체

 

객체 간의 관계에서 상위에 있는 것이 항상 하위보다 추상적이어야 한다.

 

👆 의미적 추상체

class Login {
	void login() {}
}

class GoogleLogin extends Login {
	void login() {}
}

Login클래스, GoogleLogin클래스의 login메서드는 각각의 구현체를 가지고 있다.

 

👆 추상 기능을 가진 객체

abstract class Login {
	abstract void login();
}

class GoogleLogin extends Login {
	@Override void login() {}
}

추상 클래스: 하나 이상의 추상 메서드를 포함하는 클래스

GoogleLogin클래스(구상체)는 Login클래스(추상체)의 login 메서드를 구체화시켜야 하는 의무를 가진다. (반드시 Override 해야 함)

 

👆 객체 자체가 추상적

interface Login {
	void login();
}

class GoogleLogin implements Login {
	@Override void login() {}
}

인터페이스(interface): 모든 것이 다 추상으로만 이루어진 객체

인터페이스는 구현된 메서드를 가질 수 없다.

 

다형성

 

형(type)을 여러 가지로 표현할 수 있다.

 

class GoogleLogin implements Login {
	@Override void login() {}
}

public void main(String[] args) {
    GoogleLogin gl = new GoogleLogin();
    Login l = new GoogleLogin();
}

같은 인스턴스(new GoogleLogin())더라도 여러가지 형으로 표현이 가능하다.

구체 클래스의 추상 클래스로 표현이 가능하다.

 

🤔 다형성이 필요한 이유 (예제)

abstract class Login {
    public abstract void login();
}

class GoogleLogin extends Login {
    @Override
    public void login() {
        System.out.println("Google 로그인을 수행합니다.");
    }
}

class AppleLogin extends Login {
    @Override
    public void login() {
        System.out.println("Apple 로그인을 수행합니다.");
    }
}

public static void main(String[] args) {
    Login googleLogin = new GoogleLogin();
    Login appleLogin = new AppleLogin();

    performLogin(googleLogin); // Google 로그인을 수행합니다.
    performLogin(appleLogin); // Apple 로그인을 수행합니다.
}

public static void performLogin(Login login) {
    login.login();
}

performLogin() 메서드는 로그인 방식에 상관없이 모든 로그인을 처리할 수 있다.

performLogin(googleLogin)을 호출하면 Google 로그인을 수행하고, performLogin(appleLogin)을 호출하면 Apple 로그인을 수행하므로 로그인 기능을 일관되게 처리할 수 있다.

 

✅ 정리

interface Login {
    void login();
}

interface Portal {
    void portal();
}

class Google implements Login, Portal {
    @Override
    public void login() {
    }

    @Override
    public void portal() {

    }
    
    public void onlyGoogle() {}
}

public void main(String[] args) {
    Login googleLogin = new Google();
    googleLogin.login();
    
    Portal googlePortal = new Google();
    googlePortal.portal();
}

googleLogin과 googlePortal은 같은 Google이라는 객체지만, 누가 접근하냐에 따라 필터링된 기능을 제공한다.

즉, Login형인 googleLogin은 Login인터페이스가 가지는 login메서드에만 접근이 가능하고 Portal형인 googlePortal은 Portal인터페이스가 가지는 portal메서드에만 접근이 가능하다. 

 

이들의 관계를 이미지로 살펴보면 다음과 같다.

추상화, 다형성을 통해 Google클래스의 login메서드는 Login형만 접근이 가능하고, portal메서드는 Portal형만 접근이 가능하고, onlyGoogle메서드는 Google형만이 접근 가능하게 하여 캡슐화를 지켰다.

 

객체 간의 협력 관계에서 자유롭게 사용되지만 안전하게 사용할 수 있는 형태이다.

---

3. UML

 

UML은 "Unified Modeling Language"의 약자

소프트웨어 시스템을 시각적으로 모델링하고 설계하기 위해 사용되는 표준화된 그래픽 언어이다.

UML은 객체 지향 개념을 기반으로 하며, 시스템의 구조, 동작, 상호작용, 행위 등을 다양한 다이어그램으로 표현할 수 있다.

 

객체 지향 프로그래밍: 기능을 객체에게 나눠서 수행시킨다.
=> 객체를 어떻게 구분했다.
=> 객체간의 연관관계가 어떠하다.

 

이러한 설계를 설명하기 위한 도구: UML

- Usecase Diagram

- Sequence Diagram

- Package Diagram

- Class Diagram

 

Tool 사이트: https://app.diagrams.net/, https://staruml.io/

 

https://makerj.tistory.com/272

 

Generalization (일반화)

 

상속 또는 확장 관계를 나타내며, 한 클래스가 다른 클래스의 특성과 동작을 상속받는 관계이다. 일반적으로 "is-a" 관계로 표현다.

형태: B -▷A

A가 추상체, B가 구현체
B가 A를 상속했다. (extends)
A가 B의 일반화 형태이다. (추상화)

Realization (실체화)

 

클래스가 인터페이스를 구현하는 관계

클래스가 인터페이스의 모든 메서드를 구현해야 한다.

형태: B --▷A

B가 A를 implements 한다

 

Dependency (의존)

 

한 클래스가 다른 클래스에 의존하는 관계

한 클래스가 다른 클래스의 메서드를 호출하거나 해당 클래스의 인스턴스를 사용하는 경우 의존 관계가 형성된다.

형태: A --> B

A가 B를 의존한다.
A가 동작하기 위해서는 B가 있어야 한다.

 

Association (연관)

클래스 간의 연결을 나타내는 관계

한 클래스가 다른 클래스와 관련이 있음을 표현한다.

 

Directed Association (직접 연관)

 

연관 관계에서 한 클래스가 다른 클래스를 가리키는 방향성을 명시하는 관계

일방향 또는 양방향으로 표현될 수 있습니다.

형태: A -> B

A가 B를 사용한다.
주체: A. 대상:B

 

Aggregation (집합, 집합연관)

 

전체와 부분 간의 관계

한 클래스가 다른 클래스의 집합을 포함하는 경우 집합 관계가 형성된다.

집합 관계에서는 전체 객체가 부분 객체들에 대한 소유나 책임을 갖지 않습니다.

형태: A ◇- B, A ◇-> B

B가 없어도 A 스스로 존재 가능하다.

 

Composition (합성, 복합연관)

 

전체와 부분 간의 강한 관계

한 클래스가 다른 클래스의 구성 요소로서 존재하며, 전체 객체가 부분 객체들을 소유하거나 책임지는 관계입니다.

형태: A ◆- B, A ◆-> B

B가 없으면 A가 존재할 수 없다.

 

✅ 정리

객체 지향 프로그램을 설계를 표현하기 위해 필요한 것

- 객체를 무엇으로 만들었는지 (필드, 메서드)

- 객체들 사이의 관계는 어떠한지

---

4. 객체지향 설계

 

🤔 어떻게 하면 객체지향을 잘할 수 있을까?

=> 객체를 잘 나누고 연관 지을 수 있느냐?

 

객체지향 설계를 하는 5가지 원칙

 

- S: SRP(Single Responsibility Principle) 단일 책임 원칙, 객체가 수정되는 경우 수정되는 이유는 하나 때문이어야 한다.

- O: OCP(Open-Closed Principle), 수정에는 닫히고, 확장에는 열어라.

- L: LSP(Liskov Substitution Principle), 추상객체로 사용되는 부분에 구상객체가 들어가도 아무 문제없어야 한다.

- I: ISP(Interface Segregation Principle) 인터페이스 분리 원칙, 인터페이스에 의존하지 않도록 분리하라.

- D: DIP(Dependency Inversion Principle) 의존성 역전 원칙

 

원칙에 따라서 설계를 해봤더니 여러 가지 경우에서 공통점이 보였다.

=> 23가지의 디자인 패턴 

참고: https://refactoring.guru/design-patterns/catalog

 

 

Reference
UML: 클래스 다이어그램과 소스코드 매핑