23.08.23 항해 99 16기 프로그래밍 기초2 5일차

오늘 공부한 것

* 팀과제였던 숫자야구를 솔리드 5원칙에 맞게 수정해보기

* 4주차 강의 학습

 

오늘은 어머니를 병원에 모시고 다녀와해서

오전시간은 공부를 하지 못했다

 

담당 기술 매니저님께서 숫자야구를

솔리드 5원칙에 맞게 수정해 보라고 말씀하셨다

 

솔리드(SOLID) 5원칙

 1) 단일책임 원칙(Single responsibility principle) SRP

     모든 클래스는 하나의 책임만 가지며, 완전히 캡슐화 해야 함.

 2) 개방-폐쇄 원칙 (Open/closed principle) OCP

     소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다

     잘 적용되었다면 기능을 추가 하거나 변경해야 할 때 이미 동작하고 있던 코드를 변경하지 않아도 새로운 코드를

     추가함으로써 기능의 추가나 변경이 가능

 3) 리스코프 치환 원칙 (Liskov substitution principle) LSP

     프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다

     자식 클래스는 언제나 부모 클래스의 기능을 대체할 수 있어야 한다

 4) 인터페이스 분리 원칙 (Interface segregation principle) ISP

     클래스가 여러개의 기능을 가진 큰 인터페이스를 구현하는 대신 자신이 실제로 필요한 작은 인터페이스만 따로

     만들어 사용

 5) 의존관계 역전 원칙 (Dependency inversion principle) DIP

     프로그래머는 추상화에 의존해야지 구체화에 의존하면 안된다

 

이렇게 다섯가지 원칙이었다

이를 맞추기위해 객체화 및 추상화 하여 작업을 하였는데.. 

실패했다 정확하게 이야기하면 아직 객체화와 추상화에 대한 개념이 부족한거 같다

 

거의 4시간 넘게 잡고 있다가 이도저도 안될꺼 같아서

4주차 강의를 학습했다

 

오류 일반적으로 회복이 불가능한 문제 시스템 레벨에서 또는 환경적인 이유로 발생

        어떠한 에러로 프로그램이 종료되었는지 확인 후 대응

 

예외 일반적으로 회복이 가능한 문제 코드레벨에서 할 수 있는 문제상황에 대한 대응은 “예외처리”에 속함

         1) 코드실행 관점

           (1) 컴파일 .java 파일을 .class 파일로 컴파일 할 때 발생 자바 프로그래밍 언어 규칙을 지키지 않아서 발생 문법에                                맞게 작성

           (2) 런타임 컴파일은 잘되었지만 “프로그림”이 실행도중 맞닥뜨리게 되는 예외

        2) 예외처리 관점

           (1)  확인된 예외 컴파일 시점에 확인하는 예외 반드시 예외 처리를 해줘야 하는 예외

                                     이미 특정 문제를 인지하고 있어서 예외 처리를 정의해 두었고 컴파일 하는 동안 예외처리를

                                     했는지 확인 할수 있는 예외

            (2) 미확인된 예외 런타임 시점에 확인되는 예외 예외 처리가 반드시 필요하지 않음

 

예외처리 방법 예외를 어떻게 정의하고, 발생 할 수 있음을 알리고 사용자는 예외가 발생 할 수 있음을 알고 핸들링하는지

                        1) throws 메서드 이름 뒤에 붙어 예외 사항을 던질 수 있는지 알려줌 여러 종류의 예외 사항을 적을 수 있다

                            throw 실제로 예외 객체를 던질 때 사용 예외 객체 하나와 같이 써야함 메서드가 종료됨

 

JAVA의 Throwable Class 모든 객체의 원형인 Object 클래스에서 시작함

                                 “문제 상황”을 뜻하는 Throwable 클래스가 Object 클래스를 상속함

                                  Throwable 클래스의 자식으로 앞서 배운 에러(Error)와 예외(Exception) 클래스가 있다

                                  에러(Error)와 예외(Exception) 클래스는 각각 IOError 클래스, RuntimeException 클래스와 같이

                                  구분하여 처리됨

 

Chained Exception 예외는 다른 예외를 유발할 수 있다 예외A가 예외B를 발생시켰다면 예외 A는 B의 원인 예외이며

                                  원인 예외를 새로운 예외에 등록한 후 다시 새로운 예외를 발생시키는데, 이를 예외 연결이라고 함

                                  1) 예외 연결 여러 가지 예외를 하나의 큰 분류의 예외로 묶어서 다루기 위함

                                                       checked exception을 unchecked exception으로 포장 하는데 유용하게 사용되기도함

                                  2) initCause () 지정한 예외를 원인 예외로 등록하는 메소드

                                  3) getCause () 원인 예외를 반환하는 메소드

 

실제 예외 처리하는 방법 1) 예외복구 가장 기본적인 방식이지만, 현실적으로 복구가 가능한 상황이 아닌 상황이 많거나

                                                            최소한의 대응만 가능한 경우가 많기 때문에 자주 사용되지 않음

                                        2) 예외 처리 회피

                                        3) 예외 전환 예외처리에 더 신경쓰고 싶은 경우나, 오히려 RuntimeException처럼 일괄적으로

                                                              처리하기 편한 예외로 바꿔서 던지고 싶은 경우 사용 함