(개념 정리) OOP

OOP

프로그램이 대형화 되고 대량 생산이 필요하게 되면서 등장한 방법으로, 큰 프로그램을 작은 단위로 분리해서

객체들 단위로 파악함으로써 각각의 프로그램은 메시지를 주고받고 데이터를 처리 할 수 있게된다.

대략적인 구조

장점

• 프로그램을 작은 기능이나 목적에 따라 나뉘었기 때문에 프로그램이 유연하고 변경이 용이함
• 프로그램을 학습하는데 더욱 편리하고 개발과 보수하기가 더 편리해졌다.
• 코드가 간결해 지므로 직관적으로 코드를 분석할 수 있다는 장점이 있다.

단점

• 처리 시간이 절차 지향 프로그래밍 보다는 오래 걸린다.
• 프로그램 설계할 때의 전문성과 많은 시간을 요구함.

OOP 5대원칙

• S(SRP : Single Responsibility Principle,  단일 책임 원칙): 한개의 클래스는 하나의 책임만 가져야함, 클래스를 변경하는 이유는 단 하나의 이유여야 한다.
  • 배달어플에 음식점이라는 클래스에 주문하기, 음식메뉴, 리뷰 서비스를 전부 담당하는 아니라 각각의 클래스 마다 한개의 책임을 부여함으로서 변경이 일어나도 그 서비스를 공유하는 음식점들이 모두 공통으로 적용된다.
• OCP(Open-Closed Principle, 개방 폐쇠 원칙): 클래스는 확장에는 열려 있고, 변경에는 닫혀 있어야 한다.
  • JDBC를 사용하는 사용자는 데이터베이스가 MySQL에서 Oracle로 바뀌더라도 연결을 설정하는 부분 외에는 따로 수정할 필요가 없다.
• LSP(Liskov Substitution Principle, 리스코프 치환 원칙): 상위 타입의 객체를 하위 타입으로 바꾸어도 프로그램은 일관되게 동작해야 한다.
  
  • 배달어플에서 주문에서 할인주문으로 바뀌어도 주문이라는 서비스는 일관되게 동작한다 생각하면 편하다.
• ISP(Interface Segregation Principle):인터페이스 분리 원칙): 클라이언트는 이용하지 않는 메소드에 의존하지 않도록 인터페이스를 분리해야 한다.
  
  • 유저 정보의 개인정보 수정, 주소 수정이 있다면 이것은 수정이라는 한개의 동작에 묶여있는게 아니라 서로 다른 동작으로 분리를 해야한다.
• DIP(Dependency Inversion Principle, 의존 역전 법칙): 클라이언트는 추상화(인터페이스)에 의존해야 하며, 구체화(구현된 클래스)에 의존해선 안된다.
  
  • 결제에 대한 기능을  삼성페이, 카카오페이, 네이버페이로 결제할지 모르니 페이는 추상화 시켜서 결제 부분이라는 것을 무조건 삼성페이다. 카카오페이다. 정의하지 않고 정의만 해두는 것.