클린코드 5장(객체와 자료구조), 6장 (오류처리)

JAVA/클린코드|2020. 6. 29. 11:25

 

객체와 자료구조


  • 객체에서 자료를 세세하게 공개하는 것 보다 추상화를 통해 표현하는 것이 더 좋다.
  • 객체는 동작을 공개하고 자료를 숨긴다.
  • 복잡한 시스템을 짜다보면 새로운 함수가 아니라 새로운 자료타입이 필요한 경우가 발생하는데 이 때는 클래스와 객체 지향 기법이 적합하다. 하지만 새로운 함수가 필요하다면 절차지향 코드와 자료구조 형태가 더 적합한 코드이다.

 

 

 

 

오류처리


 

  • 오류를 일일히 처리하는 것보다 차라리 예외를 던저버리는게 더 깔끔하다.
  • 확인된 예외를 처리하기 위해서 하위 메소드에서 throws를 하게되면 상위 메소드에서 이 예외에 대한 명시가 되어야 하기 때문에 하위의 예외 때문에 상위 메소드가 수정되어야 하는 불상사가 발생하기 때문에 수정에 닫혀 있어야 하다는 OCP규칙을 위반한 것이다.
  • 예외에 의미있는 내용을 함께 던져서 의미 파악에 도움이 되게 하라.
  • 에러가 발생하였을 때 null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 일감을 더 주게 되는 문제가 있다.
  • 에러를 모두 한 곳에서 처리하게 되면 아래와 같이 귀찮게 된다. 이를 매번 open()을 사용하는 곳에서 처리하게 되면 엄청나게 귀찮게 되고 의존성이 있어 하나의 오류가 늘어나게 되면 모든 사용하는 곳에서 처리를 해줘야 한다. 그래서 이를 별도의 클래스를 만들어서 클래스 내부에서 innerPort.open()을 실행시키게 해서 그 곳에서만 에러 내용을 처리해주고 정재된 Exception만 다시 던지게 하는 것도 방법이다.
// 문제
public void open() {
	try { 
		innerPort.open();
	} catch (DeviceResponseException e) {
		...
  } catch (NetworkErrorException e) { 
		...
  } catch (BindingException e) {
    ....
  } catch ....

} 


// 감싸기 클래스 사용
public class LocalPort {

  private ACMEPort innerPort;

  public void open() {
		try { 
			innerPort.open();
		} catch (DeviceResponseException e) {
			// 내부에서 약속된 하나의 에러 패턴을 사용.
			throw new PortDeviceFailuer(e);
	  } catch (NetworkErrorException e) { 
			throw new PortDeviceFailuer(e);
	  } catch (BindingException e) {
			throw new PortDeviceFailuer(e);
	  } catch ....
	  }
	}
}

 

 

 

 

결론

에러처리를 잘못하면 코드가 굉장히 더러워진다. 실제로 많이 경험해봤고 아직도 어렵다. 중요한건 내부에서 발생한 에러로 인해 상위에서 호출하는 함수의 코드가 변해야 하는 OCP 위반 사항을 발생시키지 않도록 하는 것 같다.

댓글()

프로그래밍 코드 작성 시 주요원칙

단일 책임 원칙 (Single Responsibility Principle) SRP
-> 객체는 오직 하나의 책임만을 가져야한다.
-> 객체에서 책임이라고 한다면 객체의 역할을 의미한다.

좋은 설계란
=> 기본적으로 시스템에 새로운 요구사항이나 변경이 있을 때 가능한 한 영향 받는 부분을 줄여야 한다.

프로그램의 요구사항은 계속해서 변경되기 마련이다.
이를 위해서 항상 변경이 가능하도록 조치가 되어있어야 하며, 이런 시스템이 변화에 잘 적용되도록 설계되어 있는지 확인 하는 것을 회귀 테스트(regression)라고 한다.

개방폐쇄원칙 (Open-Closed principle) OCP 
- 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 한다.


리스코프 치한원칙 
- 자식클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야한다.
- 자식 클래스와 부모클래스 사이의 행위가 일관성이 있어야 한다.
- is a kind of 관계 사이를 유지하라.

의존 역전 원칙 Dependency Inversion Priciple 
- 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다는 변화하기 어려운 거, 거의 변화가 없는 것에 의존하라.
- 아이가 장난감을 가지고 노는 행위자체는 변화하기 어렵지만, 가지고 노는 장난감은 변화가 쉽다.
- 행위를 적는 인터페이스는 변화가 적고, 실채가 있는 구체 클래스는 변하기 쉽다.

인터페이스 분리 원칙 (Interface Segregation Principle)
- 복합기라는 하나의 커다란 인터페이스를 구현한 팩스 클래스가 갑작스러운 복합기 기능의 변경으로 인해 인터페이스가 변경되면 영향을 받을 수 있다. 그러한 이유로 자신이외에 다른 곳에서 크게 사용하지 않는 특징일 경우 별도의 인터페이스로 관리하는 것이 좋다.
- 진짜 변하지 않는 인터페이스를 상속 받아 재 구현한 인터페이스를 이용하여 클래스를 구현하는 방식을 이용하면 된다.
- SRP (단일 책임 원칙)을 생각하면서 인터페이스도 분리를 해야한다.

결론.
하나의 객체의 하나의 역할을. 관련이 없는 것 끼리는 서로 독립시킬 것.
섣부른 상속은 큰 문제를 야기할 수 있다.



'IT 지식 > 소프트웨어 공학' 카테고리의 다른 글

프로그래밍 코드 작성 시 주요원칙  (0) 2018.05.30
피터 코드의 상속 규칙  (0) 2018.05.30

댓글()