Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[사다리 - 3단계] 김성환 미션 제출합니다. #24

Open
wants to merge 1 commit into
base: fanngineer
Choose a base branch
from

Conversation

fanngineer
Copy link

사다리 미션 3단계 제출합니다.
앞서 2단계에 주신 질문 중에 PointsGenerator를 static으로 구현한 이유는, Line 객체마다 동일하게 사용지만 매번 새로 객체를 할당할 필요가 없다고 생각해서 static으로 선언했습니다.
3단계는 사다리 결과를 정하기 위해서 이전 구현 조건 중 연속해서 연결된 부분이 등장할 수 없다는 점을 활용했습니다.
이를 통해서 Ladder에서 아래로 내려가며 Line을 확인하며, 각 Line에서 Point들을 탐색하면서 Point의 연결 여부가 true일때는 앞뒤의 결과를 swap하도록 구현했습니다.
의문점이나 피드백 남겨주시면 감사하겠습니다.

Copy link

@seokhwan-an seokhwan-an left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

성환님 3단계 구현하시느라 고생하셨습니다.
리뷰 남겼는데 확인 부탁드립니다!

사다리 미션 3단계 제출합니다.
앞서 2단계에 주신 질문 중에 PointsGenerator를 static으로 구현한 이유는, Line 객체마다 동일하게 사용지만 매번 새로 객체를 할당할 필요가 없다고 생각해서 static으로 선언했습니다.

답변 확인했습니다. 추가로 드리고 싶은 질문은 싱글톤 패턴을 이용하면 static과 마찬가지로 Line 객체마다 동일한 PointsGenerator 객체를 사용하면서 객체를 한번 생성하면 그 이후로는 새로 생성할 필요가 없을 것 같은데 static과 싱글톤은 어떤 기준으로 이용하면 좋을 것 같나요?

@@ -4,10 +4,21 @@
import java.util.List;

public class Ladder {
private final List<Participant> participants;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ladder에서는 Participant를 직접 의존하는 것보다 사다리를 타는 과정에서만 협력을 하는 방안은 어떻게 생각하시나요?
혹시 Participant를 직접 의존하신 이유는 무엇인가요?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

저는 일반적으로 사다리게임이 1회성이라 생각해서 하나의 사다리게임 안에 참여자들이 속해있다고 생각해서 그처럼 구현했습니다. 그런데 말씀 듣고나니 고정된 생각을 벗어나서 의존성을 줄이는 방법으로 구현하는게 좋을 것 같아 반영하겠습니다!

this.lines = generateLines(ladderSize, lineSize);
getResult();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

해당 메소드는 객체 생성 시 동작하는 것보다는 생성 후에 동작을 하는 것이 좋을 것 같습니다!
저는 개인적으로 생성자에서는 객체 생성의 역할까지만 수행해야한다고 생각합니다!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

저도 분리하는 방향을 생각하다가 사다리게임 시작시에 결과가 정해진다고 생각해서 그렇게 했는데, 위와 같은 맥락으로 분리하는게 좋을 것 같네요!

Comment on lines +20 to +22
public void setEnd(int end) {
this.end = end;
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

이 메소드는 결국 setter의 기능이기는 하지만 move 혹은 이동의 의미를 나타내는 명칭을 이용하는 것이 코드를 읽은 과정에서 가독성이 좋을 것 같습니다!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

좋은 의견 감사드립니다😄

Comment on lines +38 to +54
private void changeByLine(Line line){
for(int i = 0; i< line.getPoints().size() ; i++){
changeByPoint(i,line.getPoints().get(i));
}
}

private void changeByPoint(int idx, Point point){
if(point.isConnected()){
swapEnds(idx);
}
}

private void swapEnds(int idx){
int temp = participants.get(idx).getEnd();
participants.get(idx).setEnd(participants.get(idx+1).getEnd());
participants.get(idx+1).setEnd(temp);
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

랜덤으로 생성된는 사다리에서 해당 메소드가 잘 동작하는지를 직접 돌려가면서 확인해가는 비용보다는 테스트 코드를 작성해서 확인하는 것이 보다 효율적일 것 같습니다. 해당 부분에 대한 테스트 작성해주세요

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants