개인적인 생각입니다! 해당 initialize는 stringCalculator 안에서 하는 것은 어떨까요? 아래 있는 코드 run은 와닿지만, defaultDelimiters를 stringCalculator를 이용해 initialize화 하는 부분에서는 stringCalculator 클래스 안에 있어도 되지 않을까 생각이 듭니다!
main에서 정의하...
> 외부에서 유틸 객체들을 DI 받고 있긴한데, 결합도를 더 낮출려면 어떻게 리팩토링하는게 좋을까요 ?? 🤔
각 DI 되는 객체들을 단위 테스트 한 뒤에 안전성을 보장하는 것이 우선이라고 생각합니다.
이후, Fake 객체나 Mock 객체와 같이 예상하는 동작의 객체를 주입함으로써 순수하게 기능에 대해서만 테스트 할 수 있을 것 같습니다!!
안녕하세요 사빈님. 코드 잘 읽었습니다. 변하지 않을 상수들에 대해선 미리 final static 으로 선언하는게 좋아 보여요. 상수가 코드에서 그대로 쓰일 경우 변화에 취약하거나 의도를 파악하기 어렵습니다. 또한 Application 클래스가 너무 많은 기능을 담당하고 있는 것 같아요. 기능에 따라 분리해보면 좋을 것 같습니다. 구글에서 "객체지향 ...
안녕하세요 사빈님. 코드 잘 읽었습니다. 변하지 않을 상수들에 대해선 미리 final static 으로 선언하는게 좋아 보여요. 상수가 코드에서 그대로 쓰일 경우 변화에 취약하거나 의도를 파악하기 어렵습니다. 또한 Application 클래스가 너무 많은 기능을 담당하고 있는 것 같아요. 기능에 따라 분리해보면 좋을 것 같습니다. 구글에서 "객체지향 ...
> OutputView 에서 결과를 BigInteger 타입으로 받고 있기 때문에 동일한 타입을 사용한거에요~ 그리고 이름 그대로 정수형을 더하는 메서드 이기 때문에 파라미터 변경이 필요하다면, 다른 메서드로 선언하는게 맞다고 보거든요~ 지환님 생각은 어떠신가요 ~??
뒤늦게 제 의견을 보완하자면 입력의 한계를 Integer로 제한하신 것 같은데...
정확히 제 의도를 파악하셨습니다 ㅎㅎ
맞습니다! Calculator를 interface로 구현한 이유는 확장성을 고려했기 때문입니다.
현재는 덧셈(sum)의 요구사항만 있지만, 추후 뺄셈, 곱셈, 나눗셈 등 다양한 연산 기능을 추가할 수 있는 가능성을 염두에 두었습니다!
> 저는 단순히 Exception을 검증 로직에서 IllegalArgumentException를 바로 던지게 구현했었는데, 이렇게 Exception을 더 구체화시켜서 던져주니 코드의 가독성이 더 좋아졌다고 생각합니다! 지금은 CalculatorException만 구현되어 있는데 각각의 예외상황에 맞는 Exception을 더 세분화해서 구현해봐도 좋을 ...