커스텀 구분자를 받게 되었을때 숫자를 분리시켜줄 구분자 정규식을 생성해주는 로직입니다!
joining메서드를 설명하자면
첫 번째 파라미터: 각 요소를 이어 붙일 때 사이에 들어갈 구분자입니다.
두 번째 파라미터: 연결된 문자열의 앞에 추가할 내용입니다.
세 번째 파라미터: 연결된 문자열의 뒤에 추가할 내용입니다.
지금 현재 코드에서는 nullable 하지 않습니다. 빈 리스트가 들어와도 0으로 반환이 되지만, integerList가 null로 들어왔을 때의 처리는 좀 더 고민해봐야 할 것 같습니다.
```java
return integerList.stream()
.mapToInt(Integer::intValue)
...
제가 말씀드린게 정답은 아니에요~
다만 저는 입력(사용자가 데이터를 입력하는 행위)과 출력(사용자에게 메세지를 보여주는 행위)의 개념을 명확하게 구분하고,
더해서 책임 분리도 되면 좋지 않을까 생각했어요~
구홍님이 의도하신거를 잘 설명해주시면 그게 정답이 되지 않을까해요~ ☺️
계산기 객체를 구현할 때 현실 세계의 계산기를 떠올리며 계산한 결과 값을 기억하고 추가로 연속적인 연산이 가능하게 만들어야겠다는 생각에 result 상태값을 갖고 있고 reset() 메서드로 초기화 하는 방식으로 구현했었는데, 생각해보니 너무 현실세계 객체를 그대로 반영하려 했던 것 같더라구요😅
그래서 리팩터링하며 현재 요구사항에서 굳이 필요없는...
현재 코드에서는 기본 구분자라는 데이터를 조작할 일이 존재하지 않는 간단한 선언 형태의 로직이기에 굳이 컬렉션을 사용하지 않았습니다! 또한 컬렉션 대신 배열로 선언함으로써 기본 구분자가 2개다! 라는 사실을 고정(?)시키고 싶어 배열을 사용하였습니다.
하지만, 이번 피드백처럼 데이터를 조작할 일이 생긴다면 확실히 여러 API를 제공하는 컬렉션을 사용...
static 을 사용하게 되면
프로그램이 실행될 때 프로그램 전역적으로 생성되어
모든 객체가 이를 알 수 있게 된다고 알고 있습니다
이는 객체지향적이지 못하다는 생각이 들었고
그렇기에 상수라고 꼭 static 을 써야 하나?
라는 생각이 들었고
상수라고 해도 클래스끼리 공유하지 않는 경우가 많았기에
꼭 static 을 사용하지 않아...
저는 패턴에 대해 매칭되는 부분을 찾는 것도 "구분자 추출" 메서드의 역할이라고 생각했는데요!
아래에서 짚어주신 것처럼, find후 예외처리 하는 영역을 별도로 분리하고 pattern 변수도 static으로 정의하면
좀 더 메서드가 간결해질 것 같네요 ㅎㅎ
감사합니다 :)