자바 OOP 이야기

Jaeuk Oh·2021년 8월 3일

목록 보기

1/6

객체지향 프로그래밍(OOP, Object Oriented Programming)

객체지향 프로그래밍이란 : 프로그램을 객체로 구성하는 것
배경 : 프로그램이 대규모, 거대화되면서 등장하게 됨
아이디어 : 어떻게 큰 프로그램을 만들 것인가?
- 해결 : 작게 나눠서 개발하고 나중에 합치자
프로그램의 동작을 객체들에게 나눠서 수행(Coupling low, Cohensive high)
개념적인 용어 : 객체 / 기술적인 용어 : class, instance
객체는 작은 기능을 수행함 고로 객체와 객체는 서로 협력해야함
- 일을 작게 쪼개서 객체에게 위임하고, 서로 협력하게 하는 것
객체를 서로 구분할 필요가 있다 (type(형)으로 구분)

type 만들기(class 만들기)

package com.programmers.java;
import java.lang.*;

class MyObject extends Object implements Runnable{
    privte int a = 0; // 필드 영역
    public void run(){ // 메소드 영역
        a += 1;
    }
}

MyObject obj = new MyObject(); //객체생성

객체가 어떤 책임, 기능을 맡게 할 것인지 정하는게 개발자

객체지향의 특성

캡슐화(Encapsulation)

완성도가 있다
- 기능을 수행하는 단위로써 완전함을 갖는다
정보가 은닉되어 있다
- (밖에서 객체 내의 정보에 접근하지 못하게 한다)
- 객체는 스스로 동작할 수 있는 환경을 갖고 있어야한다
  - 외부에 의존하거나, 외부의 접근을 제한해야 한다

class Animal{ // 예시
    private Heart heart; // 접근지정자 private
    private Blood blood;
    
    void donation(){
        return null;
    }
}

class Human entends Animal{ // Human은 Animal을 상속받았지만 private인 heart와, blood에 접근하지 못함
    void run(){
        return 
    }
}

접근지정자(Access Modifier)

접근지정자	접근 범위	동일클래스	동일패키지	다른 패키지의 자식클래스	다른 패키지
public	어디서든 접근 가능	ㅇ	ㅇ	ㅇ	ㅇ
protected	동일패키지와 상속된 객체에서도 접근 가능	ㅇ	ㅇ	ㅇ
default	동일패키지 내에서만	ㅇ	ㅇ
private	동일 클래스 내에서만	ㅇ

상속(Inheritance)
- 상위 클래스, (부모, super, 추상적)
- 하위 클래스, (자식, this, 구체적)
- 오해
  - 공통된 기능을 다양한 객체에게 전달하고 싶을 때
  - 목표가 '분산'이 아니라 '상위클래스를 구체적으로 실현시키고 싶을 때' 쓰는 것이다!
  - 예시) 지구인 -> 아시아인 -> 한국인 -> 서울시민 -> 연희동 주민
  - 한국인 -> 어린 한국인 (객체지향 프로그래밍에서는 완벽하다고 보기 힘듦, 어린 한국인이라는 기준이 애매하기 때문에 비효율적)

추상화(Abstraciton)

추상화된 객체 : 추상체
구체적인 객체 : 구상체
서로 대조적인 관계
객체간의 관계에서 '상위에 있는 것이 항상 하위보다 추상적이어야 한다'

class Login{ // 의미적 추상체
    void login(){}; // 메소드를 갖고 구현화 된 상태지만 KakaoLogin 덕분에 의미적 추상체라고 본다. 즉 구체적/추상적을 나누는 기준은 상대적이다.
}

class KakaoLogin extends Login{ 
    void login(){};
}

abstract class Login{ // abstract 메소드을 가진 추상클래스, interface와 차이는 구체화된 메소드나 요소가 존재할 수 있다.
    abstract void login(); // 구현화 안 된 상태
}

class KakaoLogin extends Login{ 
    @Override void login(){}; // 구현화된 상태
}

// 객체자체가 추상적
interface Login{ // 모든 것이 다 추상으로만 이루어진 객체 ==  interface
    void login(); // 구현화 안 된 상태
}

class KakaoLogin implements Login{ 
    @Override void login(){}; // 구현화된 상태
}

다형성(Polymorphism)

type(형)을 여러가지로 표현할 수 있는 성질

interface Login{ // 모든 것이 다 추상으로만 이루어진 객체 ==  interface
    void login(); // 구현화 안 된 상태
}

interface Portal{ // 모든 것이 다 추상으로만 이루어진 객체 ==  interface
    void portal(); // 구현화 안 된 상태
}

class KakaoLogin implements Login{ 
    @Override void login(){}; // 구현화된 상태
}

class NaverLogin implements Login, Portal{ 
    @Override void login(){}; // 구현화된 상태
    @Override void portal(){}; // 구현화된 상태
}

Login login = new Login();
Login login= new KakaoLogin();
Login login = new NaverLogin();

Portal potal = new NaverLogin();
//이렇게 만들면 potal은 NaverLogin의 객체지만 
// void login()에 접근 불가능함 
// 이를 위해서 추상화를 하는것임
// 권한을 가진 부분만 주고, 서로의 접근을 막기위해

추상 클래스를 만드는 이유
- 추상관계를 만들 수 있기 때문
- 예를 들어, 회사에서 로그인 기능을 제공하는데 구글이나 네이버 계정 연동으로도 가능하게 만들고 싶다. 이때 같은 로그인 결과를 도출해도 기업 연동 로그인을 각자 접근 권한 없는 부분을 침범하지 않기 위한다고 보면 편할 듯.

UML(객체지향설계1, 어떻게 하면 객체지향을 잘 할 수 있는 것인가)

객체지향 프로그래밍 : 기능을 객체에게 나눠서 수행시킨다
- 객체를 어떻게 구분했다
- 객체 간의 연관관계가 어떠하다
설명하기 위한 도구 : UML (따로 정리해서 블로그에 올리기)
- Usecase Diagram
- Sequence Diagram
- Package Diagram
- Class Diagram(제일 중요!!!)
  - Tool : draw.io
    - A ->(일반화) B
      - B는 부모, A는 자식클래스
      - 일반화 == 추상화
      - A는 B를 상속받다
    - A ->(실체화) B
      - B는 인터페이스, A는 implements 받음
    - A ->(의존) B
      - A가 B를 의존한다
    - A ->(집합) B
      - A가 B를 소유한다
      - 색칠되어 있으면 꼭 있어야하는 관계

객체지향설계 2

어떻게 하면 객체를 잘 나누고 연관지을 수 있는가?
- 객체지향 설계를 위한 5가지 원칙(SOLID)
- (SOLID 자세한 설명: 여기로 오세요!)
SRP(Single Responsiblity Principle, 단일 책임 원칙)
- 수정이 필요할 경우 수정되는 이유는 하나 때문이어야 한다
- 최대한 객체가 가진 기능은 1개로 해라
OCP(Open-Closed Principle, 개방-폐쇄 원칙)
- 수정에는 닫히고, 확장에는 열어라
- 확장해서 기능을 바꿀 수 있도록 설계해라
LSP(Liskov Substitution Principle, 리스코프 치환 원칙)
- 추상객체로 사용되는 부분에 구상객체가 들어가도 아무 문제가 없어야 한다
- 상속을 단순하게 공통기능을 뿌리기 위한 기능으로 사용한다면 LSP를 위배할 수 있다
- 추상과 구상의 관계가 잘 되어있다면 위배할 수 없는 원칙
ISP(Interface Segregation Principle, 인터페이스 분리 원칙)
- 인터페이스를 나눠서 써라
- 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다.
DIP(Dependency Inversion Principle, 의존성 역전 법칙)
- 의존 관계를 맺을 때 변화하기 쉬운 것 보다 변화하기 어려운 것에 의존하라
- 추상적인 것보다 구체적인게 변하기 쉽다
GoF의 디자인패턴
- 이런 SOLID 원칙에 따라서 설계를 해보니깐 다양한 경우에서 공통점들이 생기게 됨
  - 이런 공통점들을 모아놓은 것이 GoF의 디자인패턴(1994년)
  - 23가지 패턴이 존재
  - 참조 : https://refactoring.guru/design-patterns