if문 밖으로 return 빼내기 - if문 밖에 변수를 먼저 선언해둘 것!
알고리즘 공부 안하니 잊는 것은 이리도 쉽다.
- 내가 원하는 것 - return 값을 if문 바깥으로 빼오는것.
- 실패했던 사유 - 저 변수가 참이면 return true, 아니면 false로 설정해놔서.
(메서드 return형을 boolean으로 설계해서 거기에 사로잡힘) 마지막에 if문 한번 더 걸어서 못 뺐음. - 해결방법 - 마지막 if문 지웠음.
@Transactional
public boolean userValidation(@RequestBody HttpServletRequest request) {
String token = jwtUtil.resolveToken(request);
Claims claims;
boolean valid = false;
// 토큰검증해서 유효한 경우만 게시물 관련 작업 가능하게 하고싶음
if (token != null) {
// Token 검증
if (jwtUtil.validateToken(token)) {
// 토큰에서 사용자 정보 가져오기 - 사용자가 존재하는지도 이미 여기서 검증!
// 근데 이건 사용자 존재여부 검증임.
// 이 사용자가 게시글 작성자랑 같은지 확인하는건 별개 문제.
claims = jwtUtil.getUserInfoFromToken(token);
} else throw new IllegalArgumentException("유효하지 않은 토큰입니다.");
// 토큰에서 가져온 사용자 정보를 사용하여 DB 조회
User user = userRepository.findByUsername(claims.getSubject()).orElseThrow(
() -> new IllegalArgumentException("사용자가 존재하지 않습니다.")
);
// token에서 검사한 사용자와 게시글 작성자가 같은지 알고싶다면,
// token subject에 username 들어감. 이걸 가져오고 싶음.
valid = claims.getSubject().equals(user.getUsername());
}
return valid;
}
영철 매니저님의 코칭
-
Wrapper class? 참조형으로 쓰라구요? 무슨 말인지 모르겠어요🤔
-> 자료형을 'int'로 선언하지 말고 'Integer' 라고 선언해달라는 것임. 이거 원빈 멘토님이 말씀하신 boxing, unboxing 개념과 관련있다!
-> null을 담을 수 있느냐 없느냐의 차이가 굉장히 크다. Wrapper class는 기본값이 0이 아니라 null임. 그래서 null에 대한 핸들링이 가능하다.
-> 기본형으로 선언할 경우 null이 들어오면 핸들링 못하고 에러가 펑! 그냥 프로그램이 나가버린다.
-> 이건 내가 어떻게 처리할 수 없는 에러임. 이런 경우를 만들지 않으려고 Wrapper class로 선언해달라고 하는 것임.
-> 이렇게 Wrapper class로 선언해주는걸 boxing, 그걸 기본 자료형으로 풀어주는걸 unboxing 이라고 한다! -
생성자에 있는 this.contents = contents; 하고 다른 메서드에 있는 this.contents = contents;는 전혀 다르다! 그냥 형태만 같은 것.
-> 그러면 반대로 생각해보자. 왜 같다고 생각해? 생성자가 뭔데? 생성자는 왜 쓴다고 생각해?
-> 생성자는 인스턴스 변수를 초기화해서 쓸수 있게 해주기 위한 것.
-> 그러니 생성자에 쓰인게 형태가 같다 한들, 그건 그냥 인스턴스 변수를 사용 가능케 하기 위한 작업일 뿐. -
나는 남들의 코드를 많이 보는 것이 필요하다. '일반적으로 많이 쓰는' 코드의 형태를 익히는게 필요함.
메소드가 굳이 필요한가요? 왜죠? 그냥 인스턴스화 하면 안돼요? 😥😥😥😥😥
Getter랑 Setter알아? 왜 쓰는것 같아?
-
남들이라고 불편하고 귀찮은게 좋을까? 그럼에도 불구하고 쓰는 이유가 뭘것 같은지?
-
Spring에서 보면 알겠지만, Service의 기능들은 전부다 public으로 선언되어 있는데 변수들이나 의존성 주입하는거 보면 전부다 private이다. 왜 그럴까?
-> Class 자체를 숨길 수는 없다. Class에 private을 붙일 순 없어. 하지만 그렇다고 나머지(변수나 메서드)까지 전부다 훌훌 풀어놓을 순 없는 것이다.
예를 들면 주민번호 같은거 다루는 변수나 메서드 풀어놓을건가? 큰일 날것. -
그러니까 Class는 원래 숨길수 없는 놈이니까 어쩔 수 없지만, 그 안에 있는 요소들만이라도 숨기자는 것.
이게 정보의 은닉이고 캡슐화로 가는 과정이다. 객체지향의 핵심 개념중 하나고.
this. 이 무엇일까? 인스턴스 변수와 매개변수를 구분하는 방법.
-
this.변수명 = 변수명; 이라면, 좌항은 뭐고 우항은 뭘까?
-> 나는 바깥에서 우항에 있는걸 받아올거야. 그리고 이 메서드 안에서 좌항의 이름으로 쓸거야! 근데 이름이 같으니까 this. 로 구분할거야!
-> 밖에서 받아온 값(매개변수)을 이 메서드 안에다가 넣고 쓸건데(인스턴스 변수),
둘이 동명이라 this. 로 인스턴스를 표시해주는 것. 이 메서드(this)의 변수임! 이라고 구분해주는 것. -
얘 this. 왜쓰는걸까? 없애려면 어떻게 하면 될것 같아?
-> 변수명을 다르게 해주면 된다! 별거 없어. 애초에 this. 붙이는 이유가 둘이 이름이 같기 때문임.
그러므로 이름이 다르면 붙일 이유도 없다. -
'클래스는 설계도' 라는 개념에 좀 집중할 필요가 있다. 어디에 쓰려고 만들었을까? 를 생각해보자.
문제점 진단 & 해결방안
-
보통 사람에 비해 기능명세를 받아들이는 것의 차이가 좀 크다. 나같은 경우는 남의 코드를 많이 보면서, '일반적으로 많이 쓰이는 코드의 스타일'을 많이 익혀보는 것이 좋다. 생각이 많은 편이고, 뭔가 너무 멀리까지 생각한다는게 보이는 코드.
-
주어진 것에 대해 뭔가를 비틀어보려는 생각을 안함. 그냥 주어진 것 안에서만 해보려고 하면 당연히 어려움. 그 부분에 대해 고정관념이 강함. -> 뭐든 좋으니까 갖고와서 써봐!
-
그래서 구현에 너무 집중을 한 탓에, 기능의 의도를 생각 안한건 아닌가? 라는 코드로 보임.
-
이론을 먼저 딱 익힌 다음에 다음을 진행하려고 하는 편. 그래서 기본지식은 있는데 코드를 못짜거나 예상 밖의 형태로 짬. '보편적 형태의 코드'를 짜는 훈련 필요.
사람마다 스타일이 다르므로 어려움 겪는 부분도 다 다름. 고쳐질 가망이 없는 부분은 아님. 훈련을 통해 충분히 사회화 가능한 부분으로 보임. -
원하는게 게임업계로 다시 돌아가는 것이라면, 웹개발 공부를 하는 것만으로는 확실히 다른 사람들에 비해 상대적으로 동기부여가 약해서 힘들 수 있다. 지금도 그래보임. 그러니 자신만의 다른 동기부여를 만들 것.
-
게임 관련 개발자를 하고 싶다면, 진짜 게임개발자의 코드를 보고 내가 얼마나 이해를 하는지 테스트를 해보는 것도 좋다.
