💡1-2차 세미나에서 새로웠던 내용을 나눠봅시다!💡

[sohyundoh]

Github Discussion을 이용해 나솝 서버들의 시선 톺아보기

1-2차 세미나 내용이나 과제에서 새롭게 배운점을 자유롭게 공유해봅시다!

• 이런 내용은 파트원들과 공유해보고 싶다! 라는 내용을 마음껏 공유해주세요!
• 파트원들과 나누고 싶은 질문이 있다면 남겨주세요!

1-2차 세미나가 끝나고 새로 배워보고 싶은 내용이 있다면 남겨주세요!

• 파트장이 세미나를 준비하는데 도움을 얻을 수 있게 새로 배워보고 싶은 내용을 마구마구 남겨주세요!

Discussion을 적극 활용해 새로운 Discussion을 직접 생성하고 질문하는 경험을 가져보는게 어떨까요?

[mini-min]

1차 세미나에서도 살짝 파짱님이 언급하시기도 했고,
저도 이번 1차 실습 과제를 하면서 PR에 질문사항으로 남긴 내용이라 같이 얘기 나눴으면 좋겠어서 남깁니다!

"추상 클래스와 인터페이스를 각각 어느 상황에서 구분해서 사용할 수 있는지"가 스스로 공부해도 조금 헷갈리네요ㅜ
혹시 이 부분을 조금 구체적으로 설명해주실 분 계실까요??

[chaewonni]

와 공감.
저도 이거 궁금해요!!!

[Chan531]

고수들 답변해줘 저도 궁금합니다 ㅋㅋㅋ

[gardening-y]

저도 번호표 뽑았어요

[ckkim817]

22222

[mini-min]

<[아티클] 추상클래스와 인터페이스 차이점 제대로 이해하기> 노션 링크페이지입니다🥺

오..고수는 아니지만 왕초보 스터디 겸 호기심 해결 겸 해당 질문에 대해 공부해서 아티클 작성했습니다!
구경오시겠어요 여러분..?

[hyerinhwang-sailin]

1. 리펙토링할 때 어떤 기준을 가지고 접근해야하는지 궁금합니다.
2. main의 코드는 짧을수록 좋은지 궁금합니다.

[Chan531]

제 개인적인 생각을 남기자면

Q. 리펙토링할 때 어떤 기준을 가지고 접근해야하는지 궁금합니다.
A. 리팩토링이라는 일이 워낙 범주가 크다고 생각해서 약 8명의 yb에게 pr을 남기면서 공통적으로 느낀 점을 토대로 답변을 드리고자 합니다!
결론적으로 메소드마다 최소한의 책임을 담아보려고 노력한다면 좋은 리팩토링이 될 수 있다고 생각합니다.
많은 분들이 하나의 메소드에서 너무 많은 일을 하고 있다는 생각이 들었습니다.
메소드 분리만 해도 조금 더 가독성 있고 깔끔한 코드를 짤 수 있을 거라고 생각합니다!
일단 이렇게 한다면 또 다음 리팩토링에 대해서도 생각할 수 있을 거 같아요!

Q. main의 코드는 짧을수록 좋은지 궁금합니다.
A. 보통 main은 프로그램을 실행시키는 일?만 하면 된다고 생각해서 모든 프로그램의 로직을 main에 담는 것은 좋지 않다고 생각합니다!
1주차 과제였던 은행 프로그램 설계에서는 BankManager 같은 main에 적을 코드를 대신 담을 은행 시스템 매니저 클래스를 따로 작성하여 여기에 프로그램에 대한 로직을 담는 것이 좋다고 생각합니다!

[lreowy]

과제하면서 코드를 '객체지향'적으로 짜야 한다는 게 뭔가 하면서도 되게 어렵고 추상적으로 느껴졌는데, 다른분들은 클래스 설계를 할 때 팁이 있는지 혹은 고려하면 좋은 부분들이 있다면 뭐가 있는지 참고하고 싶습니다..!

[Chan531]

제 개인적인 생각을 말하자면 일단 바로 코드를 작성하지 말고 종이에다가 클래스를 설계하면서 각 클래스에 어떠한 책임을 맡기는게 좋은 설계일지 생각해보는 것이 좋다고 생각합니다.

바로 코드를 짜면 나중에 더 좋은 설계가 떠올라도 수정이 번거롭기도 하고 일단 뭐든지 기초 설계를 탄탄히 하고 작업을 들어가는게 좋다고 생각합니다~