(위 질문하고 비슷하다고 생각해 여기에 함께 적습니다)
저는 코드를 한 번에 주욱 짜 두고 불편하지 않으면 (굳이) 뽑지 않아요. 뽑아내는 것도 하나의 리소스이기도 하고, 미래를 예견하는 건 어렵기 때문이죠 😢 보통 저는 바로 읽을 수 있는 곳에 적어두는 편이었습니다. 이것도 사람마다 취향이 참 다르고, 결국 팀 안에서 약속을 한다면 좋다고 생각해요...
전체적으로 물흐르듯이 controller에서 호출해서,separatorManager, StringHandler,Validator 전체적인 흐름다좋아요 이런식으로 발전시키는구나 한수 배웠습니다 그런데 StringHandler에서 이미 separatorManager기능 이미 다해서 굳이 separatorManager필요없어도 될거같습니다 세부적으로 나눈점...
개인적인 생각입니다! 해당 initialize는 stringCalculator 안에서 하는 것은 어떨까요? 아래 있는 코드 run은 와닿지만, defaultDelimiters를 stringCalculator를 이용해 initialize화 하는 부분에서는 stringCalculator 클래스 안에 있어도 되지 않을까 생각이 듭니다!
main에서 정의하...
> 외부에서 유틸 객체들을 DI 받고 있긴한데, 결합도를 더 낮출려면 어떻게 리팩토링하는게 좋을까요 ?? 🤔
각 DI 되는 객체들을 단위 테스트 한 뒤에 안전성을 보장하는 것이 우선이라고 생각합니다.
이후, Fake 객체나 Mock 객체와 같이 예상하는 동작의 객체를 주입함으로써 순수하게 기능에 대해서만 테스트 할 수 있을 것 같습니다!!
안녕하세요 사빈님. 코드 잘 읽었습니다. 변하지 않을 상수들에 대해선 미리 final static 으로 선언하는게 좋아 보여요. 상수가 코드에서 그대로 쓰일 경우 변화에 취약하거나 의도를 파악하기 어렵습니다. 또한 Application 클래스가 너무 많은 기능을 담당하고 있는 것 같아요. 기능에 따라 분리해보면 좋을 것 같습니다. 구글에서 "객체지향 ...
안녕하세요 사빈님. 코드 잘 읽었습니다. 변하지 않을 상수들에 대해선 미리 final static 으로 선언하는게 좋아 보여요. 상수가 코드에서 그대로 쓰일 경우 변화에 취약하거나 의도를 파악하기 어렵습니다. 또한 Application 클래스가 너무 많은 기능을 담당하고 있는 것 같아요. 기능에 따라 분리해보면 좋을 것 같습니다. 구글에서 "객체지향 ...
> OutputView 에서 결과를 BigInteger 타입으로 받고 있기 때문에 동일한 타입을 사용한거에요~ 그리고 이름 그대로 정수형을 더하는 메서드 이기 때문에 파라미터 변경이 필요하다면, 다른 메서드로 선언하는게 맞다고 보거든요~ 지환님 생각은 어떠신가요 ~??
뒤늦게 제 의견을 보완하자면 입력의 한계를 Integer로 제한하신 것 같은데...
정확히 제 의도를 파악하셨습니다 ㅎㅎ
맞습니다! Calculator를 interface로 구현한 이유는 확장성을 고려했기 때문입니다.
현재는 덧셈(sum)의 요구사항만 있지만, 추후 뺄셈, 곱셈, 나눗셈 등 다양한 연산 기능을 추가할 수 있는 가능성을 염두에 두었습니다!