✍ Today I Learned
Java 스터디 3일 차
우리 조의 기존 스터디 룰은
월~금: 개인 공부 / 토: 각자 맡은 챕터 발표였으나
함께 하는 시간을 더 의미 있게 보내고자 다른 방식을 제안해보았다.
정해진 양을 다 같이 미리 공부해오고, 이해가 어려웠던 부분이나 궁금한 내용을 공유하는 방식으로!
다행히 조원분들도 의견에 동의해주셔서 앞으로는 이런 방식으로 스터디가 진행될 것 같다.
오늘은 각자 공부해온 06-1 객체지향 프로그래밍 부분을 공유하였다.
확실히 함께 이야기 나누다 보면 내가 어떤 부분을 모르는지 깨닫게 되는 것 같다.
다음은 오늘 스터디 시간에 나누었던 내용이다.
- 객체가 생성되면 어디에 저장되는가?
- new 연산자로 메모리 힙 영역에 객체를 생성하고, 이후 객체 번지를 리턴한다.
- 클래스 변수는 무엇이고, 어떤 역할을 하는가?
- 클래스 변수는 static 키워드를 가진 변수로 클래스가 메모리에 올라가면서 메소드 영역에 저장되어 인스턴스를 생성하지 않고도 바로 사용할 수 있다. 해당 클래스의 모든 인스턴스가 공유해야 하는 값을 유지하기 위해 사용된다.
- 메소드와 생성자의 차이는 무엇인가?
- 메소드는 어떠한 특정 작업을 수행하기 위한 명령문의 집합이다. 생성자는 객체의 생성과 동시에 인스턴스 변수를 초기화하는 일종의 메소드이다. 둘의 차이는 이름과 리턴 값에서 알 수 있는데, 생성자는 클래스와 같은 이름을 가지고 있고 리턴 값이 없지만 리턴 타입을 void로 선언하지 않는다.
당연하게 생각했던 부분을 직접 말로 설명하려니까 바로 답이 나오지 않았다.
어떤 개념은 헷갈리기도 했고.. 조원분의 설명으로 이해가 된 부분도 있었다.
이런저런 의견을 나누다 보니 30분이 훌쩍 지나버렸다.
굉장히 유의미한 시간이었다고 생각한다. 앞으로의 시간들도 성장의 계기가 될 수 있기를!
int와 Integer의 차이
알고리즘 문제를 열심히 풀다가 조원분이 SOS를 쳐서 다 함께 그분의 코드를 보게 되었다.
나는 아직 풀지 않은 부분이었기 때문에 큰 흐름 정도만 보았고,
문제를 풀었던 다른 조원분은 그다지 틀린 부분이 없어 보인다고 했다.
하지만 지독하게도 15번 테스트 케이스'만' 계속 실패가 떴다.
뭔가 데이터 타입을 알맞게 사용하지 않았을 거라 생각하고
이곳저곳의 int를 long으로 변환해봤지만 여전히 15번에서 계속 걸렸다.
그러다 결국 본인이 틀린 부분을 찾아내셨다.(ㅋㅋㅋㅋ)
놀랍게도 ==(동등 비교 연산자)를 equals() 수정해주었더니 바로 통과가 되었다..!
왜 그런 걸까?
비교를 하던 값은 문자열도 아니고, ArrayList<Integer> 에서 for문을 통해 하나씩 꺼내온 리스트의 요소였다.
아 설마 int가 아니라 Integer라서..? 바로 구글링에 들어갔다.
그렇다. 언뜻 같다고 생각할 수 있지만 int와 Integer는 엄연히 다르다.
int는 primitive type이고, Integer는 primitive type을 객체로 다루기 위해 사용하는 wrapper class이다.
따라서 값 비교에도 차이가 있다.
비교 대상 중 primitive type의 변수가 하나라도 있다면, == 연산자는 변수가 가리키는 값을 토대로 비교한다.
그러나 wrapper class끼리 비교하는 경우, == 연산자는 각 객체의 주소 값을 비교하므로 의도한 결과와 다른 결과가 나왔던 것이다.
이럴 때는 값 자체의 비교를 위해 equals()를 이용해야 한다.
어찌 보면 당연한 내용인데, 무심코 코드를 짜다보면 놓치기 쉬운 부분인 것 같다.
※ 참고 자료
int와 Integer는 무엇이 다른가
int와 Integer는 무엇이 다른가 // 기본부터 다시 시작하기
velog.io
Java의 Integer, int 숫자 비교의 주의사항
예전에 프로그램에 버그가 있었고 원인을 한참을 못찾은적이 있었다.숫자 비교하다 생긴 문제였고, 무심코 코딩하다 틀리고 삽질할 수 있는 부분이라 블로그에 남겨본다.ㅎㅎ 아래는 숫자를 저
marobiana.tistory.com
코드 리뷰의 목적?
저번 옆 조에서의 경험을 발판으로 알고리즘 조원들끼리 나름의 코드 리뷰를 하기 시작했다.
본인이 생각했던 로직과 흐름을 설명하면서 서로 풀이했던 내용을 공유하는 방식으로 진행하고 있는데
우리가 잘하고 있는 게 맞는지 의문이 들었다.
기술 매니저님께 우리가 하고 있는 코드 리뷰를 설명하면서 더 효율적인 방법이 있을지에 대해 여쭤보았다.
매니저님께서는 코드 리뷰의 목적을 다시 상기시켜주셨는데,
- 내가 푼 방법 말고, 다른 사람의 풀이 방법 체득
- 내가 풀었던 방법을 다시 한번 말로 설명
이 2가지를 충족한다면 크게 걱정하지 않아도 된다고 말씀해주셨다.
결국 큰 틀 안에서 세부적인 내용은 팀에서 만들어가는 약속이라고 생각한다.
오늘만 해도 다른 조원분들의 풀이를 보며 문제 해결을 위한 길이 더 많아졌다고 느꼈다.
곧 알고리즘 주간이 끝나지만, 의식적으로 이런 자리를 자주 만들어야겠다.
오늘의 나는
달리기반에 제공되었던 마라톤 문제 총 24개 중에 오늘까지 23개를 해결했다.
문제를 쑥쑥 풀어내던 초반에 비해 하루에 2~3문제가 한계였던 막바지가 참 힘들었다.😢
그래도 일주일 전의 나라면 상상도 못 했을 일이다. 하면 되는구나 진짜.
이제 막 발을 뗐을 뿐이다. 알고리즘은 남은 항해 기간에도 꾸준히 공부할 생각이다.
내일 있을 본 테스트도 잘 마무리했으면 좋겠다!
'📝 TIL' 카테고리의 다른 글
[TIL] 2주차 주특기 입문ㅣ주간 시작 (0) | 2022.11.25 |
---|---|
[TIL] 2주차 알고리즘 테스트 (0) | 2022.11.24 |
[TIL] 2주차 알고리즘 모의고사 (4) | 2022.11.22 |
[TIL] 2주차 알고리즘 코드 리뷰, Java 스터디 (0) | 2022.11.21 |
[TIL] 1주차 알고리즘ㅣ문제 풀이 꿀팁 (0) | 2022.11.19 |