-
Notifications
You must be signed in to change notification settings - Fork 0
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
[feat] 1주차 과제 제출 #2
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM👍🏻 첫 과제 고생하셨습니다!!
저도 잘하지 못하다보니 영주님처럼 처음에 어떤 부분을 어떻게 나눠야할까 고민을 많이했던 것 같아요. 저도 과제를 할 때, 프로그램의 구조를 나누면서 생각한 것들을 같이 공유해볼게요!
일단 main은 무거우면 안된다는 생각입니다.
-> 결국 말이 어려워서 그렇지 OOP는 클래스든, 모듈이든 객체로 분리해서 만들어두고 이것들을 호출하면서 사용하라는 뜻이거든요!
main 한 곳에만 코드를 몰게 되면, 가독성 측면도 있겠지만, 2차 세미나 마지막에 다뤘던 테스트 코드 적용이나 무엇보다 코드의 유연성 측면(기존 코드를 수정하고, 새로운 기능을 추가하고)에서 불편함이 많아질거에요.
지금은 입출금과 송금 기능만 구현해서 과제를 제출하셨지만, (설상 나중에 이 프로그램을 더 건들지 않는다고 하더라도) "추후에 다른 기능이 추가될 수 있다는 가능성"을 혹은 "기존 기능의 변경사항이 발생할 수 있는 가능성"을 생각하신다면 더 좋을 것 같습니다 ^__^
뭐 예를 들어 나중에는 송금하기 위해서 계좌 비밀번호를 입력하는 기능을 추가한다고 했을 때,
지금처럼 Account의 필드를 만들고, 함수를 추가하고, 생성자도 변경하고, 그러면 Main에 어느 부분을 수정해야했지...같은 문제가 생길 수 있다는 점을 고려하시면
"아 내가 이 부분을 나누면 수정할 때 조금 용이하겠네!"라는 생각이 들 것이라 생각합니다!
- 추상 클래스나 인터페이스를 만들어서 활용해보시는 연습을 권장드립니닷!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
과제하느라 고생하셨습니다!
앞으로 과제하실 때 패키지 구조와 접근제어자를 잘 이용해보는게 어떨까요? 객체지향의 핵심은 책임을 분리하는 것입니다!
영주님의 과제에는 Account와 Main으로 두 개의 클래스로 모든 걸 담당하고 있으니 이걸 분리하는 방안을 고민해보시면 좋을 것 같아요!
예를 들어 입출력 모듈을 다른 클래스로 분리한다던지, 고객 클래스를 따로 정의하는 방법도 좋을 것 같습니다!
앞으로 계속해서 발전할 과제 기대할게요🍀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1주차 과제 수고하셨습니다!
계좌개설 부터 프로그램 종료까지 6개의 기능을 구현하셨다는 점이 대단하신 것 같습니다!
저도 소현님과 민재님과 동일한 의견입니다.
main 클래스의 책임이 많다고 느껴집니다. 이는 프로그램의 유연성 뿐만 아니라 가독성이 떨어지게 됩니다. 그래서 추후에 리팩터링 하실 때 MVC 패턴을 적용해 볼 것을 권유드립니다!
MVC 패턴은 설계시 기능과 모듈 단위로 계층을 나누는 방법으로 객체 지향 프로그래밍에서 깔끔하고 효율적인 코드 구조를 만들기 위해 사용됩니다. 아마 MVC를 공부하시고 리팩터링을 하시게 되면 아! 이 부분에서 컴포넌트를 하나 추가해서 책임을 분산시켜야 겠다! 라는 생각이 드실 겁니다.
또한 저도 잘 적용시키지 못했지만, 인터페이스와 추상클래스를 이용해서 SOLID 원칙을 지키도록 구현해 보시면 좋겠습니다.
저도 리팩터링 과정에서 적용하려고 생각중인데, 예를 들어 입금과 출금기능을 담당하는 인터페이스를 구현하고 두 인터페이스를 Account 클래스에서 구현하는 방법이 있을 것 같습니다!
Account ac=findAccount(account_num); | ||
if(account_num == null) System.out.println("없는 계좌입니다."); | ||
else{ | ||
ac.deposit(money); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
account_null은 위에서 sc.nextInt()로 받은 결과물인 것으로 보이는데, 여기서는 account_num == null를 검사하는 것이 아닌, 함수 호출로 부터 받은 ac객체를 검사(ac == null)해야 할 것 같다고 생각됩니다!
영주님은 어떻게 생각하시나요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
추가로 아래와 같이 try-catch로 예외처리를 해주시면 account_num이 숫자가 아닌 입력일 경우 예외처리를 할 수 있을 것 같습니다!
public static void depositService() {
System.out.println("입금 서비스 입니다.");
System.out.print("입금할 계좌번호 입력 : ");
String account_num = scanner.nextLine();
try {
System.out.print("입금할 금액 입력 : ");
int money = sc.nextInt();
sc.nextLine();
Account ac = findAccount(account_num);
if(ac == null) {
System.out.println("없는 계좌입니다.");
} else {
ac.deposit(money);
}
} catch (InputMismatchException e) {
System.out.println("유효하지 않은 금액입니다. 숫자를 입력해주세요.");
sc.nextLine();
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
setter는 사용되지 않으므로 삭제해도 좋을 것 같다고 생각합니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
잔액과 입출금 시의 금액을 모두 money로 관리하고 계신 것 같습니다.
저도 처음에는 영주님과 동일하게 둘다 money로 변수를 구현하다가, 잔액의 money인지 입출금의 money인지 헷갈리는 경험을 했습니다. 😂
그래서 잔액은 balance, 입출금은 기존 money로 관리하니 명확히 구분할 수 있어 구현할 때 편리했었습니다.
리팩터링 할때 이 방법도 생각해보시면 좋을 것 같습니다!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Scanner 객체를 함수 호출시마다 생성하고 계신 것으로 보입니다.
Main함수 위에 private static final Scanner scanner = new Scanner(System.in);로 전역적으로 선언하면 호출시마다 생성할 필요 없이 바로 sc.메서드로 입력을 받을 수 있습니다!
Account ac=findAccount(account_num); | ||
if(account_num == null) System.out.println("없는 계좌입니다."); | ||
else{ | ||
ac.withDraw(money); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
account_null 관련해서 위와 동일한 의견입니다!
과제 하시느라 너무 고생 많으셨어요 ! 영주 님두 현재 Accout 클래스는 따로 모듈화 하는 것 까진 성공 하셨으니 조금씩 클래스를 더 세분화 시켜 책임 분리를 시키며 객체지향적으로 조금씩 조금씩 고도화 해보시면 어떨까 싶습니다 !
|
Related Issue 📌
Description ✔️
Main
계좌 생성 메서드
계좌 목록 보여주는 메서드
입금 메서드
출금 메서드
계좌이체 메서드
계좌 목록 확인 메서드
Account 클래스
필드와 생성자
입금, 출금, 계좌이체
To Reviewers