객체지향 OOP에 대한 정리

ACABERRY와 함께하는 프로그래밍 공부

객체지향 OOP에 대한 정리

나무위키
https://namu.wiki/w/%EA%B0%9D%EC%B2%B4%20%EC%A7%80%ED%96%A5%20%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

1) 프로그램을 단순히 데이터와 처리 방법으로 나누는 것이 아니라, 프로그램을 수많은 '객체'라는 기본 단위로 나누고 이 객체들의 상호작용으로 서술하는 방식이다.

2) 이 OOP가 나오게 된 배경은 절차적프로그래밍의 순서도로 나타낼수 없는 전략시뮬. 이를 절차적코드로 만들시 스파게티 코드( 함수/메소드 기능비대, if-else얽힘, 콜백 3~5단계초과, 다중루프, 포인터남용 등 )로밖에 구현 불가능한 내용을 중복코드 / 입력 / 계산 / 출력 등 역할별로 나뉘어 기능을 분리할 수 있어 유지 / 보수가 용이하다는 측면.

3) 요소로는 캡슐화 / 상속 / 다형성.

  3-1) 캡슐화는 접근제한을 두어 내부처리를 알지못하게 ( 몰라도 되도록 ) 설계 - public / protected / private

  3-2) 상속은 부모 클래스의 특성과 기능을 물려받아 사용. ( 재정의[덮어쓰기] - 오버라이딩 -으로 재사용 용이 )

  3-3) 다형성은 오버로딩[다중/중복정의]로 매개변수만 다른 동일한 이름의 함수를 활용

4) 장단점 : OOP 특성은 자료분석 / 개발시간▼ / 정확학코딩 대신 코드의 난이도가 높아짐.

SOLID. 객체지향법칙.

https://namu.wiki/w/%EA%B0%9D%EC%B2%B4%20%EC%A7%80%ED%96%A5%20%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D/%EC%9B%90%EC%B9%99

Single Responsibility Principle
객체는 오직 하나의 책임을 가져야 한다. (객체는 오직 하나의 변경의 이유만을 가져야 한다.)

Open Closed Principle
객체는 확장에 대해서는 개방적이고 수정에 대해서는 폐쇄적이어야 한다는 원칙

Liskov Substitution Principle
자식 클래스는 언제나 자신의 부모 클래스를 대체할 수 있다는 원칙

Interface Segregation Principle
클라이언트에서 사용하지 않는 메서드는 사용해선 안된다.

Dependency Inversion Principle
추상성이 높고 안정적인 고수준의 클래스는 구체적이고 불안정한 저수준의 클래스에 의존해서는 안된다는 원칙

―――― ACABERRY's STUDY ―――― ACABERRY's STUDY ―――― ACABERRY's STUDY ――――

▶대부분 퍼온 내용이기에 출처를 꼭 명시합니다.

▶문제되는 부분이 있다면 요청주시면 언제든 수정 & 삭제합니다.

▶포스팅의 목적은 공부하시는 분들이 쉽게 접하고 정답을 찾아가는데 도움을 드리고자 함입니다.

―――― ACABERRY's STUDY ―――― ACABERRY's STUDY ―――― ACABERRY's STUDY ――――