예를들어 Board 클래스에 삭제 메소드가 있는데 삭제요청이 게시글 작성자 본인인지 확인하고 동일하면 삭제되도록 함.
그래서
Board안에 delete(User user) {......}
이렇게 User클래스의 객체를 받는 메소드를 만들어서 구현하러고 하는데 생각해보니까 이거도 클래스끼리 직접적으로 결합된거같음.
그래서 User는 인터페이스로 선언하고
쓸때는 저 인터페이스를 구현한 **user 클래스를 쓰려고 하는데 이게 맞음?
계층간의 결합도를 낮춰야하는건 알겠는데
이런 같은 계층의 클래스끼리 상호작용할때도 인터페이스를 만들어서 서로의 결합도를 낮추는게 맞음?
국비충을 살려주세요
그래서
Board안에 delete(User user) {......}
이렇게 User클래스의 객체를 받는 메소드를 만들어서 구현하러고 하는데 생각해보니까 이거도 클래스끼리 직접적으로 결합된거같음.
그래서 User는 인터페이스로 선언하고
쓸때는 저 인터페이스를 구현한 **user 클래스를 쓰려고 하는데 이게 맞음?
계층간의 결합도를 낮춰야하는건 알겠는데
이런 같은 계층의 클래스끼리 상호작용할때도 인터페이스를 만들어서 서로의 결합도를 낮추는게 맞음?
국비충을 살려주세요
delete는 순수하게 삭제만하고 유저인증은 앞에 다른 코드로 되어야 함 - dc App
인증된 유저를 위한 board 클래스를 만들던지. board를 인터페이스로 하고 유저 정보를 이미 들고있는 UserBoard 라던가 - dc App
os 파일 읽기쓰기 생각해봐라.. 권한 없는 파일 읽으려고 하면 실패하잖아. read함수에 넘겨주는건 fd하난데 fs가 어캐 인증하겠노? os 로그인 세션 정보를 지가 알아서 가져오는거임 - dc App
뭐 이런 방식이 항상 맞다는건 아니고 일반적으로 이렇게 디자인한단거임 - dc App
그럼 굳이굳이 board가 자체적으로 검증하게 구현할려면 board에서 세션정보든 뭐든 직접 가져와서 처리해야한다는거???
내 말은, 보드 라는 것을 서비스로 보고 같은 서비스를 구현할 때 기능의 수준이 다른 구현으로 레이어를 나눌 수 있다는 거임. 가장 본연의 역할을 수행하는, 삭제 라던가, 아마 db에 바로 붙을 테니 DbBoard 라고 하자. 그리고 그거 앞에 인증을 수행하고 다음 단계로 포워드만 하는 UserBoard가 있겠지 - dc App
UserBoard라는 놈은 User랑 Board 인터페이를 멤버로 가지고 있음. 얘는 delete할 때 User정보릉 확인하고 들고 있는 Board 인스턴스의 delete를 호출해줌. 아마 그 인스턴스로는 DbBoard의 인스턴스가 될 수 있겠지 - dc App
UserBoard는 인증만 진행하고 실제 삭제는 어캐하는지 모름. 그냥 알수도 있는 다음 놈 한테 떠넘기는거임. 이제 DbBoard는 유저에대해 아무것도 모르고 UserBoard는 유저 인증에 대한 것 밖에 모름 - dc App
이름은 귀찮아서 대충 정했으니까 알아서 고쳐라 - dc App
다른 방식으로는 통신 채널을 추상화해서 그걸 넘겨주는 거임. Transport로 보통 추상화하는데 httptransport라는 걸 만든다고 하면 요청넣늘 때 헤더에 auth key를 추가해준다던가 서버로부터의 챌린지를 수행한다던가 하겠지. - dc App
dbboard userboard는 보통 서버에서 만들고싶어핥네고 transportBoard는 클라에서 만들고싶겠지. 잎뒤 모두 board라는 인터페이스를 사용할수 있게되는거임 - dc App
보통 userboard같은 건 잘 안만듦. 특수한 목적이 있는게 아니라면. 아마 프록시서비스같은 걸 만들고싶을 때 저런 생각을 하게 될거임. 보통 사용자 인증은 api gateway라고 서버 최앞단에서 함. 사용자 인증은 보통 모든 서비스가 필요로 하니까 - dc App
보드 말고 뭐 스토리지 서비스 라이브 스티리밍 서비스 이런거 다 유저 관점에서는 로그인 한번만 하고 인증정보 돌려 쓸텐데 서비스마다 인증 구현 따로 하진 않겠지 - dc App
와 국비과정 밟고 있는 뉴비한테 너무 어렵다 환경쪽은 아직 1도 모르는데 공부더하고 올게요 ㅠㅠ
제가 말한 board는 모델?이라고 하나 하나하나의 게시판(게시글) 그 자체인데 자기가 스스로 요청에 대한 검증을 한다는거엿는데 일반적으론 다른 계층에서 검증한다는거겟죠?
인터페이스 또는 상속을 써서 결합도 낮추려면 비슷한 성격을 가진 객체 예를들면 User 라는 인터페이스 있고 그 아래, UserAdmin, UserStep, UserNomal, UserPrime, UserBusiness 같은 애들이 유사하지만 다른 기능 가지고 쫙 있으면 인터페이스로 구현해서 넣어야지 근데 너가 만들려고 하는 시스템에 그냥 User 객체 하나만 있으면 충분하다?? 그리고 추가 확장같은건 필요없다?? 그러면 인터페이스 만들고 자시고 할 필요는 없음
아니 일단 보드가 유저를 알고있는것부터 문제임 그 이전에 유저에 대한 검증은 따로 이루어져야하고 가장 베스트는 로그인된 유저랑 보드 글쓴이 아이디값 서로 비교하는거일듯.
그리고 보통 유저를 인터페이스로 만드나? Dto 만들어서 상속해서 쓰는건 많이 봤는데 유저 자체는 인터페이스보단 그냥 만드는게 나을거같은데. 왜냐면 성질 자체가 메소드를 많이 소유하기보단, 속성을 많이 가지고 있을테니깐
ㄳㄳ 뭔가 객체지향에 대해서 공부하다보니까 로직 처리도 외부에서 코드를 나열하는게 아니라 객체들간의 상호작용으로만 처리해야된다는 잘못된 고집이 생겨버린거같음...
Jpa로 한다치면 멤버 소유하고 있긴할텐데 그래도 메소드 레벨에서 멤버가 들어가기보단 그냥 서비스 레벨에서 밖에서 온 검증된 멤버 아이디랑 보드에 있는 아이디를 비교해도되고. 사실 객체지향적으로 생각하면 검증이 보드의 책임은 맞음. 만약 그렇게 하려고 한다면 설계 나름이겠지만 나는 그냥 id 두개 비교하는 메소드 선에서 끝낼거같기도함. 굳이 인터페이스 말고도. 이건 내 생각이니깐 좀 걸러 들어
이렇게 생각하는건 한가지 가정이 필요한데, 보드 서비스에 도착한 것부터가 이미 멤버는 검증이 끝난상태라는거지, 시큐리티든 필터든 해서 ㅇㅇ
ㅇㅇㅇ 학원에서 배울때도 그냥 그렇게 배웠는데 너무 객체지향이라는 키워드에만 몰두하다보니 간단한 길을 잊어버린거같음 ㅠ