제 생각으로는 자식클래스로써 부모클래스의 private도 접근 못하고 사용하지못하는 상속 사용하는게 더 코드가 꼬이지 않을가라는 생각을 하고있습니다.
부모클래스가 private에 멤버 변수를 선언한 순간 public이나 protected로 돌려 사용하지 않는이상 자식클래스 입장에서는 사용할 수도 없는데
friend class 선언 한줄이면 private접근자도 서로 사용가능해지고 오히려 코딩하기 더 편해지지않을까요?
다형화 같은 경우에는 뭐 그럴수도있을거같아 이해는 됩니다.
하지만 굳이 자식 어미 클래스를 선언 할 필요없는 코드에서는 friend클래스가 더 좋겠다라는 생각이 들어서요.
혹시 아니라면 구체적인 예와 함께 설명해 줄 수있을까요?
답변 정말 감사합니다.
님이 알고 계신것과 같습니다.
부모 클래스의 private 도 접근을 못하지만 상속받아서 만든 클래스로 사용하면 되니까요
꼭 부모 클래스의 private 접근을 해야 한다면 당연히 friend 를 쓰겟죠
하지만 그런 경우 위의 답글처럼 기존의 코드가 영향을 미칠테니 그런 부분까지 알고 있는 개발자라면 모를까 보통은 그렇게 안하죠
문제가 생겨도 내가 추가한 코드에서 문제 생기면 되지만 그렇지 못한 버그는 찾기도, 고치기도 어려우니까요
좋다 나쁘다의 문제는 아닌거 같습니다
꼭 필요하면 써야하지만
보통은 그런 경우보다 원래 되던건 그대로 되고 - 레거시 포함 - 추가적인 동작이 기존 코드와 얽힘 없이 동작하기를 원하니까요
friend는 접근을 허용하기 위해 쓰는 것이 아니라 접근을 제한하기 위해 쓰면 의미가 명확해집니다
그게 그건데 싶지만 약간 다릅니다
예를들어 ui라이브러리를 만든다치고
대부분의 컴포넌트는 widget을 상속 받을 겁니다
어떤 자식class가 widget의 private를 억세스하기 위해 friend를 써야한다면 또는 쓸 수 있다면 잘못 설계된겁니다
맥락을 달리해서 uiconfig라는 모델/스토어성 class가 있다고 치죠.
라이브러리가 제공하는 모든 widget의 private코드에서 해당 오브젝트의 변수를 억세스해서 씁니다
하지만 widget을 상속해서 개발하는 개발자는 해당 private에 억세스 못하므로 있는 걸 알아도 쓰지를 못합니다
그렇다고 protected로 열어주면 변수가 컨텍스트에 관계없이 공개될 수 있어서 잘못사용하면 디버깅에 심각한 문제가 생기죠
그래서 굳이 uiconfig에 억세스하고 싶은 사람을 위해 uiconfigadapter를 제공하면 됩니다.
하지만 uiconfig가 public class라면 어떤 개발자는 adapter를 쓰지않고 uiconfig를 바로 상속 받아서 사용하려고 할 수 있습니다.
uiconfig를 private class로 만들고 adapter에 friend를 주면 uiconfig는 adapter에서만 접근 가능합니다.
개발자가 접근하는 창구를 단일화해서 라이브러리가 의도치 않은 방식으로 사용하는 걸 방지할 수 있고 디버깅 시에도 검색해야할 컨텍스트를 매우 줄일 수 있습니다
상속이 편해서 그런거죠
상속이 편해서 그런거죠
해당 클래스를 직접 건드리면 잘되던게 안될수도 있지만 상속해버리면 그럴일이 없으니까요
그리고 friend 를 쓰면 다형화 시키기도 어렵고 코드 꼬이짆아요 ^^
------------------------------------------------------------
ProgrammingHolic
답변 정말 감사합니다.
제 생각으로는 자식클래스로써 부모클래스의 private도 접근 못하고 사용하지못하는 상속 사용하는게 더 코드가 꼬이지 않을가라는 생각을 하고있습니다.
부모클래스가 private에 멤버 변수를 선언한 순간 public이나 protected로 돌려 사용하지 않는이상 자식클래스 입장에서는 사용할 수도 없는데
friend class 선언 한줄이면 private접근자도 서로 사용가능해지고 오히려 코딩하기 더 편해지지않을까요?
다형화 같은 경우에는 뭐 그럴수도있을거같아 이해는 됩니다.
하지만 굳이 자식 어미 클래스를 선언 할 필요없는 코드에서는 friend클래스가 더 좋겠다라는 생각이 들어서요.
혹시 아니라면 구체적인 예와 함께 설명해 줄 수있을까요?
답변 정말 감사합니다.
님이 알고 계신것과 같습니다.
님이 알고 계신것과 같습니다.
부모 클래스의 private 도 접근을 못하지만 상속받아서 만든 클래스로 사용하면 되니까요
꼭 부모 클래스의 private 접근을 해야 한다면 당연히 friend 를 쓰겟죠
하지만 그런 경우 위의 답글처럼 기존의 코드가 영향을 미칠테니 그런 부분까지 알고 있는 개발자라면 모를까 보통은 그렇게 안하죠
문제가 생겨도 내가 추가한 코드에서 문제 생기면 되지만 그렇지 못한 버그는 찾기도, 고치기도 어려우니까요
좋다 나쁘다의 문제는 아닌거 같습니다
꼭 필요하면 써야하지만
보통은 그런 경우보다 원래 되던건 그대로 되고 - 레거시 포함 - 추가적인 동작이 기존 코드와 얽힘 없이 동작하기를 원하니까요
결국 요구조건과 개발자의 역량에 달린 문제지만요 ^^
------------------------------------------------------------
ProgrammingHolic
답변 정말 감사합니다.
감사합니다 코로나 때문에 흉흉한 요즘 몸조심하세요.
감사합니다
friend는
friend는 접근을 허용하기 위해 쓰는 것이 아니라 접근을 제한하기 위해 쓰면 의미가 명확해집니다
그게 그건데 싶지만 약간 다릅니다
예를들어 ui라이브러리를 만든다치고
대부분의 컴포넌트는 widget을 상속 받을 겁니다
어떤 자식class가 widget의 private를 억세스하기 위해 friend를 써야한다면 또는 쓸 수 있다면 잘못 설계된겁니다
맥락을 달리해서 uiconfig라는 모델/스토어성 class가 있다고 치죠.
라이브러리가 제공하는 모든 widget의 private코드에서 해당 오브젝트의 변수를 억세스해서 씁니다
하지만 widget을 상속해서 개발하는 개발자는 해당 private에 억세스 못하므로 있는 걸 알아도 쓰지를 못합니다
그렇다고 protected로 열어주면 변수가 컨텍스트에 관계없이 공개될 수 있어서 잘못사용하면 디버깅에 심각한 문제가 생기죠
그래서 굳이 uiconfig에 억세스하고 싶은 사람을 위해 uiconfigadapter를 제공하면 됩니다.
하지만 uiconfig가 public class라면 어떤 개발자는 adapter를 쓰지않고 uiconfig를 바로 상속 받아서 사용하려고 할 수 있습니다.
uiconfig를 private class로 만들고 adapter에 friend를 주면 uiconfig는 adapter에서만 접근 가능합니다.
개발자가 접근하는 창구를 단일화해서 라이브러리가 의도치 않은 방식으로 사용하는 걸 방지할 수 있고 디버깅 시에도 검색해야할 컨텍스트를 매우 줄일 수 있습니다
댓글 달기