항해99[5기] 2주차 WIL[1/23]

김현진·2022년 1월 23일
0

항해 WIL

목록 보기
2/5

개념

객체지향 프로그래밍(OOP)

  • 프로그램 설계방법론
  • 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의
    독립된 단위, 즉, "객체" 들의 모임들로 파악하고자 하는 것
  • "객체" 들을 서로 유기적으로 협력하여 상호작용을 한다

구성 요소

  • 클래스(class)
    같은 종류의 집단에 속하는 속성기능를 정의한 것
    즉, 객체를 정의해 놓은 설계도
  • 객체(Object)
    실제로 존재하거나 추상적으로 생각할 수 있는 것들 중 자신의
    속성과 기능을 다른 것들과 명확히 구분할 수 있는 것
    클래스를 통해 제작된 객체를 인스턴스(Instance)라고 함
    • 속성: 멤버 변수, 필드
    • 기능: 메서드

객체지향의 3대 특징

  • 캡슐화(Encapsulation)
    변수와 메서드를 하나로 묶어 클래스로 만드는 것
    접근제어자를 통해 외부의 접근을 막아 실제 구현 내용을 감추는
    정보 은닉성을 가지고 있다
  1. 사용자가 불필요한 부분을 접근하지 못하게 하여, 객체의 오용을 방지
    할 수 있다 (개발자와 사용자는 다르다!!)
  2. 객체 내부의 기능이 바뀌더라도 그 기능을 사용하는 코드는 영향을
    받지 않는다
    -> 객체 간의 결합도가 낮아지게 된다

  • 상속(Inheritance)
    한 타입을 사용하면서 구현을 추가할 수 있도록 해주는 방법
    자식 클래스에서 부모 클래스의 기능을 받고 여기에 기능을 추가하거나
    재정의(오버라이딩) 하는 것
  1. 기존에 작성된 클래스를 재활용하여 다른 클래스에서 쓸 수 있다
  2. 클래스간의 계층 구조를 통해 다형성을 추구할 수 있다

  • 다형성(Polymorphism)
    '한 객체가 여러 가지 모습을 갖는다' 라는 의미
    '역할'과 '구현'으로 나눈다

    자동차의 역할에 어떤 실제의 자동차 구현체(K3,아반떼 등)이 와도
    운전자는 자동차를 사용하는데에 아무런 문제가 없다

    구현 대상이 바뀌어도 사용하는데 아무런 문제가 없다
    -> 유지 보수성이 뛰어나다

객체 지향의 5원칙

  • SRP(단일 책임 원칙)
    한 클래스는 하나의 책임만 가져야 한다
    하나의 책임은 크고 작을 수 있고, 문맥과 상황에 따라 다를 수 있기 때문에
    변경을 책임의 기준으로 삼으면 이해하기 쉽다
    변경이 있을 때 파급 효과가 적으면 SRP를 잘 지킨 것!

  • OCP(개방-폐쇄 원칙)
    소프트웨어는 확장에는 열려있으나 변경에는 닫혀 있어야 한다
    -> 두 가지 속성을 동시에 가져야 한다
    확장에 열려있다
    -> 새로운 변경사항이 있을 때 유연하게 코드를 추가 또는 수정할 수 있다
    변경에 닫혀있다
    -> 객체를 직접 수정하지 않고 변경사항을 적용할 수 있다
    다형성을 활용하자!
    어떤 클래스에 기능이 추가되어야 한다면 그 클래스를 직접 변경하지 않고
    인터페이스를 구현하여 새로운 기능을 구현하자

  • LSP(리스코프 치환 원칙)
    프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의
    인스턴스로 바꿀 수 있어야 한다
    다형성을 지원하기 위한 원칙
    하위 클래스는 인터페이스 규약을 지켜서 작성되어야 한다
    -> 인터페이스를 구현한 구현체를 믿고 사용하려면 LSP가 꼭 필요!
    ex) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능
    -> 구현한 클래스에서 엑셀을 뒤로 가게 만든다면 LSP위반!

  • ISP(인터페이스 분리 원칙)
    범용 인터페이스 하나보다는 특정 클라이언트를 위한
    여러 개의 인터페이스 분리가 더 좋다
    ex) 자동차 인터페이스 -> 운전 , 정비 인터페이스
    사용자 인터페이스 -> 운전자 인터페이스, 정비사 인터페이스
    이렇게 하면 정비 인터페이스가 편해도 운전자 인터페이스에 영향을 주지 않음

  • DIP(의존관계 역전 원칙)
    추상화에 의존하고 구체화에 의존하지 않는다
    -> 구현 클래스에 의존하지 말고 인터페이스에 의존하라
    구현 클래스에 의존하게 되면 변경시 파급 효과가 커지게 된다

실제 적용은?

  1. 모든 설계에 역할구현을 분리하자
  2. 최대한 모든 설계에 인터페이스를 도입하자
    -> 그러나 모든 설계에 인터페이스를 도입하기엔 비용이 클 수 있다
    -> 기능을 확장할 가능성이 없다면 구체 클래스를 직접 사용하고
    향후 꼭 필요할 때 인터페이스를 도입하여도 된다

JVM

  • 자바를 실행하기 위한 가상 컴퓨터
    자바 컴파일러는 .java -> .class(java byte code)
    이때 byte code는 기계어가 아니기 때문에 OS환경에서 바로 실행 X
    JVM은 OS의 종류와 상관 없이 OS가 byte code를 이해할 수 있도록
    해석하고 실행
    -> OS에 종속적이지 않고 자바 파일만 만들면 어디서든 JVM위에서 실행

구조

https://d2.naver.com/helloworld/1230 참고

0개의 댓글