MENU

20210914 TIL

Facts

  • 프로그래머스에서 문제를 풀고 풀이를 포스팅 했습니다.

  • 패스트 캠퍼스

    • 스프링 입문 - 객체지향 chapter수강

Feelings

  • 스프링 공부를 본격적으로 시작했습니다. 객체 지향 강의를 보는 것부터 시작했는데 이전에 객체 지향과 관한 책을 몇 개 읽었음에도 불구하고 여전히 객체 지향에 대해 명료하게 설명하지 못하는 것 같습니다. 오늘 공부한 것과 그동안 읽은 책을 참고하여 객체 지향이 무엇인지 설명할 수 있는 포스팅을 작성해야겠습니다.
  • 그동안 학습을 할 때 배운 것을 나만의 언어로 만들지 못한 것 같습니다. 나름대로 굿 노트에 정리하면서 나의 것으로 만든 것 같은데 잘 못된 방법이었나 싶습니다. 어떻게 공부할 것인가를 다시 읽어봐야겠습니다.
  • 삼각 달팽이 문제를 오랜 시간동안 못 풀었습니다. 풀이에는 근접한 것 같은데 구현이 잘 안따라 주는 것 같습니다. 다음 문제 풀이에는 알고리즘이 흘러가는 조건을 명확하게 하고 빠진 조건이 무엇인지 곰곰히 생각하면서 풀이를 시작해야겠습니다.

Findings

  • 객체 3가지 요소

    • 상태 유지 (객체의 상태)
    • 객체는 상태 정보를 저장하고, 유지되어져야 하며 이러한 속성은 변수로 정의 되어져야 한다. 이러한 속성값이 바뀜으로 인하여, 객체의 상태가 변경될 수 있다.
    • 기능 제공(객체의 책임)
    • 객체는 기능을 제공해야 한다. 이 부분은 메소드의 제공으로 이루어진다.
    • 캡슐화와 연관이 있다. 외부로 부터 직접 속성에 접급하여 변경 하는 것이 아닌 객체가 제공하는 메소드로 기능이 제공되어져야 한다.
    • 고유 식별자 제공(객체의 유일성)
    • 각 객체는 고유한 식별자를 가져야 한다.

  • 객체 : 물리 객체, 개념객체

    • 개념 객체 : 웹 시스템에서 service에서 해당되며, 비즈니스 로직을 처리하는 부분을 의미

  • 객체지향 4가지 핵심요소

    1. 캡슐화 : 객체의 속성을 보호하기 위해 사용
    2. 메소드 설계 : 속성이 선어되었으나, 이 상태를 변경하는 메소드가 없다면 잘못 선언된 속성이다.
    3. 각각의 메소드는 서로 관련성이 있어야 한다.
    4. 객체안의 메소드는 객체 안의 속성을 처리해야한다. 다른 객체의 속성을 받아 수정하면 안된다.

    5. 장점 :

      • 추상화를 제공한다. -> 실제 동작에 대해서 이해할 필요가 없다.
      • 재사용성이 향상된다. -> 모듈성 응집도가 높아짐 => 재사용성이 높아짐.
      • 유지보수의 효율성이 향상된다.
      • 무결성을 보장 -> 일반 메소드는 입력된 매개변수를 validation한 후 실행하는 것을 기본으로 한다. -> 값에 대한 유효성을 가질 수 있다.
    6. 상속 (글쎄?)
    7. 속성의 상속이 아닌 하위로 내려갈 수록 구체화 되는 것.

    8. 상속의 효과

      • 재사용성
      • 확장성 향상
    9. 다형성
    10. 하나의 개체가 여러개의 형태로 변화 하는 것
    11. 다형성을 구현하기 위해 오버라이딩을 사용한다.
    12. 추상화
    13. 모델링
    14. 공통적인 부분, 특정 특성을 분리해서 재조합 하는 부분
    15. 다형성, 상속 모두 추상화에 속한다.

  • 객체지향 설계 5원칙 (SOLID)

    • 응집도 결합도 : 좋은 소프트웨어 결합도는 낮추고 응집도는 높여야 한다.
    • 결합도 : 모듈 간의 상호 의존 정도를 나타내는 지표
    • 결합도가 낮으면 모듈간의 상호 의존성이 줄어들어서 객체의 재사용 및 유지보수가 유리하다.
    • 응집도 : 하나의 모듈 내부에 존재하는 구성 요소들의 기능적 관련성
    • 응집도가 높은 모듈은 하나의 책임에 집중하고 독립성이 높아져, 재사용 및 유지보수가 용이하다.
    • 단일 책임 원칙 : 클래스를 변경해야 하는 이뉴를 한가지 뿐 이어야 한다.
    • 개방 폐쇄 원칙 : 자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야 한다.
    • 상위 클래스 또는 인터페이스를 중간에 둠으로써, 자신은 변화에 대해 폐쇄적이지만, 인터페이스는 외부의 변화에 대해서 확장을 개발해 줄 수 있다.
    • application -> jdbc인터페이스 <- 다양한 다비들
    • 리스코프 치환 원칙 : 서브 타입은 언제나 자신의 기반(상위)타입으로 교체할 수 있어야 한다.
    • 인터페이스 분리 원칙 : 클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다.
    • 의존 역전 원칙 : 자신보다 변하기 쉬운 것에 의존하지 말아야 한다.

  • POJO(Plain Old Java Object) Java

    • 순수한 자바 오브젝트
    • pojo특징
    • 특정 규약에 종속되지 않는다. : 특정 라이브러리, 모듈에서 정의된 클래스를 상속 받아 구현하지 않는다. pojo가 되기 위해서는 외부의 의존성을 두지 않고 순수한 자바로 구성이 가능해야한다.
    • 특정 환경에 종속되지 않는다. : 특정 비스니스 로직을 처리 하는 부분에 외부 종속적인 것이 있을 경우 pojo를 위배한 것으로 간주한다. 어노테이션을 사용한 클래스도!
  • 스프링, 하이버네이트 -> 객체 지향적인 설계, pojo를 지향/ 개발자가 서비스 로직에 집중하고 이를 pojo로 쉽게 개발할 수 있도록 지원하고 있다.
  • 자신의 코드에 if/else switch가 난무하고 있는가?
  • 책임과 역할이 다른 코드가 하나의 클래스에 있는가?
  • 한개의 파일에 모든 코드를 넣고 있는가?
  • 내가 만든 객체가 재사용 가능한가?

Future Action Plans