OOP(Object-Oriented-Programming)
객체지향 프로그래밍 방식
객체지향프로그래밍 방식은 절차적 프로그래밍 -> 구조적 프로그래밍을 거쳐 개선된 형태이다.
절차적 프로그래밍 방식
입력을 받아 명시된 순서대로 처리하고 결과를 내는 방식
구조적 프로그래밍 방식
절차적 프로그래밍에서 개선된 형태로
프로그램을 함수단위로 나누고 함수끼리 호출하는 방식이다.
객체지향 프로그래밍
수많은 '객체'로 나눠 서로 상호작용하도록하는 일종의 프로그램 설계에 대한
방법론으로 특징은 아래와 같다.
1. 코드의 재사용성이 높아진다.
2. 유지보수가 쉽다.
3. 코드가 간결해진다.
객체지향의 4대 특성
1. 캡슐화(Encapsulation) = 정보은닉
접근제어자(private, public, protected)를 사용해서 객체의 외부에 내부데이터의 접근을 통제하는 것이다.
보통 public한 메소드에서만 접근가능하게 해서, 인터페이싱을 맞춘다.
2. 상속(Inheritance) = 재사용 + 확장
사실 꽤나 전부터 상속은 지양하는 경향이 있다.
그 이유가 상속은 뭔가 부모가 자식한테 물려주는 것으로 잘못이해하고 있기 때문이다.
객체 지향에서의 상속은 상위 클래스의 특성을 하위 클래스에서 상속(특성 상속)하고 거기에 더해 필요한 특성을 추가, 즉 확장해서 사용할 수 있다는 의미이다. 즉, 확장해서 사용할 수 있다는 의미이다.
객체지향의 상속은 부모-자식같은 계층도나 조직도가 아닌 동물-포유류와 같은 분류도라는 사실을 명심하자.
- 하위 클래스 - 상위 클래스
- 하위클래스 is a kind of 상위클래스
- 하위 클래스는 상위클래스 특성을 재사용하고, 확장한다.
- 상위 클래스의 물려줄 특성이 많을수록 좋다 (LSP)
- 상위 클래스가 너무 빈약하면, 불필요한 형변환이 자주 일어난다.
- 인터페이스
- 자바는 다중 상속을 할 수 없다. 다중상속 대신 도입됨.
- 어떤 객체가 해야할 일을 정의하는 추상 자료형
- 구현 클래스 is able to 인터페이스 (ex. Runnable)
- 인터 페이스는 구현을 강제할 메서드가 적을수록 좋다 (ISP)
3. 추상화(Abstraction) = 모델링
구체적인 것을 분류해서 관심영역(애플리케이션 경계)에 있는 특성만 가지고 재조합하는 것.
예를들어 class Person은 병원이라면 환자 도메인에 맞는 속성이 좀 더 많을 것이고, 상점이라면 고객입장에서의 속성이 좀 더 많을 것이다.
3. 다형성(Polymorphism) = 사용편의
오버라이딩(overriding)과 오버로딩(overloading)이 여기에 해당된다.
- 오버라이딩
- 같은 메서드 이름 / 같은 인자 목록 / 상위 클래스의 메서드 재정의
- 상위 클래스 타입의 객체 참조 변수에서 자동으로 하위 클래스가 오버라이딩한 메소드를 호출해 줌
- 오버로딩
- 같은 메서드 이름 / 다른 인자 목록 / 다수의 메서드 중복 정의
객체지향 설계 5원칙 SOLID
SOLID란 객체 지향 프로그래밍을 하면서 지켜야하는 5대 원칙으로 각각 SRP(단일 책임 원칙), OCP(개방-폐쇄 원칙), LSP(리스코프 치환 원칙), DIP(의존 역전 원칙), ISP(인터페이스 분리 원칙)의 앞글자를 따서 만들어졌다.
단일 책임 원칙(Single responsibility priciple, SRP)
SOLID원칙 중 S에 해당하는 키워드로, 단어 그대로 모든 Class는 하나의 책임만 가지며, 그 책임은 완전히 캡슐화 되어야함을 의미한다. 곧 작성된 Class는 하나의 기능만 가지며, 그 Class가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어야 한다는 원칙이다.
단일 책임 원칙을 제대로 지키면 변경이 필요할 때 수정할 대상이 명확해진다. 그리고 이러한 단일 책임 원칙의 장점은 시스템이 커질수록 극대화되는데, 시스템이 커지면서 서로 많은 의존성을 갖게되는 상황에서 변경 요청이 오면 딱 1가지만 수정하면 되기 때문이다.
OCP (개방 폐쇄의 원칙 : Open Close Principle)
개방 폐쇄 원칙(Open-Closed Principle, OCP)은 확장에 대해 열려있고 수정에 대해서는 닫혀있어야 한다는 원칙으로, 이
는 수정이 일어나더라도 기존의 구성요소에서는 수정이 일어나지 않아야 하며, 쉽게 확장이 가능하여 재사용을 할 수 있도록 해야한다는 의미이다. 여기에서 중요한 것은 추상화와 다형성이다.
객체 지향에서 다형성이란 여러 가지 형태를 가질 수 있는 능력을 의미하고 추상화란 핵심적인 부분만 남기고, 불필요한 부분은 제거함으로써 복잡한 것을 간단히 하는 것이다. 추상화를 통해 변하지 않는 부분만 남김으로써 기능을 구체화하고 확장할 수 있다. 변하지 않는 부분은 고정하고 변하는 부분을 생략하여 추상화함으로써 변경이 필요한 경우에 생략된 부분을 수정하여 개방-폐쇄의 원칙을 지킬 수 있다.
이 원칙을 무시한다면 유연성, 재사용성, 유지보수성 등을 얻을 수 없다라고 할 정도로 중요한 원칙이라고 볼 수 있다.
리스코프 치환 원칙(Liskov Substitutions Principle, LSP)
리스코프 치환 원칙은 1988년 바바라 리스코프가 올바른 상속 관계의 특징을 정의하기 위해 발표한 것으로, 하위 타입은 상위 타입을 대체할 수 있어야 한다는 것이다.
쉽게 말해서 부모 Class가 들어갈 자리에 자식 Class를 넣어도 잘 구동되어야 한다 라는 원칙이다.
예시 :
- 상위 : 사각형 - 하위 : 정사각형, 직사각형
- 상위 : 자동차/운송수단 - 하위:아반테,그렌져
인터페이스 분리 원칙(Interface Segregation Principle, ISP)
클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안된다라는 원칙이다.
이 법칙에서의 핵심 과제는 큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리시킴으로써 꼭 필요한 메서드들만 이용할 수 있게 한다이다. 이러한 원칙을 준수하면서 기대할 효과로는 시스템의 내부 의존성 관계를 느슨하게 하여 리팩토링, 수정, 재배포를 쉽게 할 수 있도록 한다.
의존성 역전 원칙(Dependency Inversion Principle, DIP)
이 원칙은 2가지 중요한 요소를 가지고 있다.
- 상위 모듈은 하위 모듈에 종속되어서는 안된다. 둘 다 추상화에 의존해야 한다.
- 추상화는 세부사항에 의존하지 않는다. 세부사항은 추상화에 의해 달라져야 한다.
모듈 간의 의존성이 강한 경우, 하나의 모듈을 수정할 때는 그 모듈에 의존성을 가진 모든 모듈에 대해서도 변경이 일어나야 한다. 하나의 모듈에 변경에도 신중할 수 밖에 없어지며 상위 모듈과 하위 모듈은 의존을 하되 추상에 의해 의존해야 한다.
'언어 > JAVA' 카테고리의 다른 글
다이아몬드 상속 문제(다중상속의 문제점) (0) | 2022.01.19 |
---|---|
디자인패턴 (0) | 2022.01.15 |
람다식(Lambda Expression) (0) | 2021.12.17 |
Stream (0) | 2021.12.16 |
Serialize(직렬화) (0) | 2021.12.14 |