private, protected는 필요한건가요?

저는 접근 권한을 구분하는 것이 매우 도움이 된다고 봅니다. 보통 private/protected
멤버는 구현에 관련된 것들이죠. 잘 설계된 클래스는 public 인터페이스만을 통하여
클라이언트가 원하는 기능을 제공하고 디테일한 구현은 감춤으로써 코드를 유연하게
만들 수 있습니다. 예를 들어 C++의 std::string과 비슷한 역할을 하는 String이라는
클래스를 만든다고 합시다. 보통 입문서에서 나오는 식으로 내부에 char*가 있고
스트링의 길이에 따라 new를 하며 복사를 할 때마다 따로 메모리를 할당하여
복사하는 식으로 구현을 했다고 가정합시다. 그런데 실제로 사용하다 보니 복사가
매우 빈번하고 따로따로 메모리를 할당하는 것이 비효율적이어서 reference
counting을 하는 식으로 구현 방법을 바꾼다고 합시다. 만약 구현에 관련된 멤버까지
public으로 했다면 클래스 구현의 변경은 거의 불가능할 것입니다. 구현이 바뀐다면
클래스의 데이터 멤버가 바뀌게 될 것이고 그 데이터 멤버를 사용한 클라이언트의
코드는 수정을 해야 하기 때문이지요. 공개용 라이브러리나 상용 코드의 경우에는
심각한 문제입니다. public 인터페이스만 그대로 두고 구현에 관련한 것들은
private/protected로 만듦으로써 필요에 따라 변경이 가능한 것이 추상화와
캡슐화의 장점 아니겠습니까.
또다른 예로 gcc의 std::vector는 _M_start라는 protected 멤버가 있습니다.
반면에 .NET에서는 _Myfirst라는 멤버가 있지요. 만약 이들이 public이어서
vector의 인터페이스를 통하지 않고 바로 접근한다면 이식성이 없는 코드가 되고
vector 클래스의 invariant도 보장할 수 없을 것입니다.
이것들이 접근 권한에 구분을 두는 것이 좋다고 보는 이유입니다.

jj님께서 getter/setter를 말씀하셨는데 이것은 충분히 추상화되지 않은 클래스에서
흔히 볼 수 있는 증상 같습니다. 디테일한 구현을 인터페이스로 위장한 것이죠.
저 같으면 클래스 설계를 다시 검토해 보겠습니다.

마틴 파울러의 리팩토링을 보면 멤버 변수를 private으로 바꾼 후에 컴파일로 그 변수를 외부에서 참조하는지 아닌지를 검사하지요.. 저는 php와 python을 주로 사용하는 코더인데요, 리팩토링을 할 때나, 꼭 리팩토링이 아니라고 해도 변수를 숨기거나 다른 곳으로 옮기고자 할때 private 키워드가 있으면 작업이 편할 거라고 자주 생각했었습니다.

그래서 요새는 변수 이름 앞에 밑줄을 붙이고 문법 검사기를 사용하는 편입니다. :)

클래스 멤버에서 변수는 private,protected로 메쏘드는 public으로
private은 외부에서 직접접근 못하므로 접근가능한 public메소드로 접근하게 만들어 써서, 클래스을 쓸때 일일이 변수이름을 확인할필요 없이 메소드로 접근하면 편하고 변수가 노출되지 않으니 잘못된 코딩을 피할수 있다고 알고 있는데 맞는건지 :oops:

저는 이 말에 동의하는 쪽에 속합니다. 특별한 경우가 아니고서는 오히려 캡슐화 자체를 약화시키는 것이 아닌가 생각합니다.

이렇게 말하신데에 대해서는 글쎄요...라고 말하고 싶네요. 위에 언급한대로 빈즈가 특수한 경우가 아닐까 합니다. getter/setter에 대한 주제는 이미 언급된 바가 있습니다.관련 주제에 대한 아티클을 하나 가지고 있어 첨부해봅니다.첨부된 아티클을 보시면 getter/setter 에 대한 문제점을 알 수 있을겁니다. 물론 언급하시는 그 Java 쪽에서 나온 문서고요.

ps. 출처는 pdf 파일 내부에 있으므로 굳이 밝히지는 않겠습니다.
ps2. 다시 보니 빈즈 얘기도 나왔었군요 ^^:

제가보기에, public, private는 반듯이 있어야 합니다.
하지만 경우에 따라서 protected보다는 package(C++에는 이러한 기능을 하는게 없죠)가 더 유용하지 않나 생각 듭니다.
public, private, package 정도만 있으면 충분하지 않을까..
protected는 경우에따라 (가급적) 없어졌으면 하는 바램이 있습니다.
회사의 프로그램이 덩치가 커지다보니 (좀 심각하게 커요..)
자잘한 protected 때문에 골치겪는 경우가 많습니다.
다른분들은 어떻게 생각하시는지...

PS:
protected 가 프로젝트와 class간의 상속관계가 좀 깊어지고, 복잡해질때 문제가 커지게 되죠..
그 protected 변수를 어느 클래스에서 상속받았고, 또 어느 상속된 클래스에서 언제 사용되었는지가 추적이 매우 용이하지 않죠..
차라리 public 과 private 만 있다면, 맘 편하게 값을 추적하면서 디버깅 할 수 있는데 말이죠...
머, 프로그램을 완벽하게 잘 짜실 수 있는 분들은... 상관 없겠지만,
여러사람이 공동작업 하는 경우에야..
내가 만지다가, 다른사람이 만질수도 있고, 내가 다른사람이 만지던걸 디버깅 할 수도 있고 하니깐요...
PS2:
에궁 protected대신 몽땅 private만 썼군요.
모두 수정했습니다.
오해 없으시길.. ^^;;

PS:
제가 학부 졸업한지 몇년정도 되서, 많이 잊어먹어서 좀 틀릴지도 모릅니다.
틀린부분 있다면 가차없이 지적해주시길.. ^^

PS2:
이거 한글 깨지는거 좀 어케 할 수 없나요 ?
너무 불편합니다.

익명씨가 제글 보시고 그런것 같군요. 쓰지 말자고 한건 아니구요. getter, setter도 좋지만(비록 전 쓰기 귀찮지만-_-), public, private도 좋지만, 패키지 레벨도 알고 쓰라는 얘기죠. 무식이 경악 스러웠다니..... ㅋ 어떻게 반응해야 할지... 허허...

객체지향 하면 흔히 말하는 Smalltalk가 public으로만 이루어졌었던 걸로 기억합니다. :-)

객체지향적인 프로그램 설계와 견고한 프로그래밍을 위한 도구는 조금 다르다는 것에 동의합니다.

대부분의 JAVA, C#, C++ 초급서는 수준이 매우 떨여졌습니다. 객체지향의 장점을 설명하는 글에 나오는 예제들이 모두 객체지향의 단점을 설명하는 예제로 역 이용 가능했기 때문입니다. 그 후에 객체지향은 깊은 사고 끝에 추상화를 얻어낼 수 있는 것은 아닐까라 생각하고 있습니다.

사람이 사고하는 방법에는 자생 적인 부분도 있지만 환경에 영향을 받는 부분도 있어서 도구가 가진 기능들이 깊은 사고에 영향을 줄 것입니다.

사고에 영향이라는 측면에서 프로퍼티는 유해한 기능이라고 생각합니다. 잘못된 구조를 매우 쉽게 구현할 수 있게 돕는 특성이고 쉽게 사람을 현혹시키는 물건이기 때문입니다. 접근자를 만들기 힘들다면 사람들은 접근자를 더 멀리 하고 더 견고하고 추상화된 객체를 만들기 위해서 노력할 것입니다.

현실 적인 이유로 실제 코드에서 접근자가 필요한 측면도 있을 것입니다. 하지만 굳이 프로퍼티가 없다고 해서 접근자의 구현이 불가능한 것이 아닙니다. 꼭 필요한 특성이 아니라 잘못된 구현을 더 쉽게 도와주는 도구이기 때문에 C#과 Visual Baisc의 프로퍼티는 신중하지 못한 언어 설계의 결과라고 생각합니다.

언어차원에서 접근자를 지원하는것에대해 긍정적으로 생각하는 편입니다.
프로그램도 사람이 하는일인 만큼, 노가다를 줄이면서, 직관적인으로 이해할 수 있고, 그리고 수정또한 용이하도록 도와주는 언어가 있다면 매우 훌륭한 언어모델일 것이다 라고 생각합니다.

프로퍼티가 그러한 일을 해 주는 도구가 아닌가 생각합니다.
프로퍼티는, 내부변수를 외부에 노출시키고 접근시키는데에 따른 코더의 노동을 줄여주고, 아무래도 줄이 짧아지는 결과를 보이다보니 직관적으로 이해할 수 있게 됩니다. 또한 이미 프로퍼티라는 함수(getter,setter)를 통해서 내부변수가 외부에 노출되어 있기 때문에 클래스 내부의 수정에 따른 객체를 사용하는 곳에서의 수정을 요하는 부하를 상당히 줄여준다고 생각합니다.
물론 함수를 통해 멤버에 접근하도록 모든 인터페이스를 제한하고, 그 함수의 이름앞에 get/set 이라는 인자를 주도록 하여서, 그 객체를 사용하는 입장에서 인식하게 할 수도 있지만, 어찌보면 키보드 타이핑의 시간이 늘어나는 결과가 되고, 또한 눈으로 읽어야 하는 줄의 양을 늘리는 결과가 되기도 합니다.

물론 맞습니다. 객체를 더욱 견고하고 추상화 되게 디자인 하는것이 매우 중요하긴 합니다만, 이는 프로퍼티와는 별개의 것이 아닌가 생각합니다. 객체의 추상화라면, member variable의 추상화가 아닌 객체들간의 inter-relation을 위한 operation의 추상화에 더욱 신경을 써야 하는게 아닌지...

저의경우 C++만 하는 편이라 - 개인적으로 C# 을 공부해 보기는 했지만, 실무에 적용시켜 보지는 못했습니다. - 프로퍼티를 실무에서 사용하면서 생기는 유지/보수 그리고 디자인/재활용 측면에서의 장/단점을 실제로 사용하시는 분들만큼 알지는 못합니다만. 저의 짧은 견식으로는 저렇게 생각합니다만...

다른분들은 리펙토링에 대해 어떻게 생각하십니까?
객체의 내용/속성 변경에 따른 문제를, 리펙토링으로 해결하면 되지 않을까 하는 생각이 들 수도 있을지 모르겠지만, 리펙토링도 그 나름대로의 한계를 가지고 있지 않나 합니다만...
리펙토링의 특징은 빠른 컴파일 & 빠른 결과확인을 통한 프로그램 수정에 필요한 피드백시간을 줄이는것에 크게 의존적인 면이 다분합니다.
하지만, 프로그램 규모가 커지게되면, 프로그램 전체를 컴파일하는데 6~10시간 정도 걸리게되면, 근본적인 부분에서 발생하는 문제에 대해서는 리펙토링을 할 수 없는 문제를 가지고 있다고 생각합니다.
프로그램 개발 방법에 따른 대세라고 생각이 되기는 하지만, 아직 많은 분야에 접목시키기에는 무리인 부분도 있지 않을까 합니다만..

PS:
에궁 어쩌다보니, 리펙토링까지 얘기가 나오게 되었네요..
^^;

^^;;;;
그렇게 처리할 수 있는게 있구, 여건상 그렇게 처리할 수 없는게 있습니다.

물론 분산컴퓨팅을 이용해서 컴파일 할 수도 있지만, VC에서 그게 수월하게 되는지는 좀 의심스럽군요.
물론 방법이 있는걸로 알고 있습니다만, 그것도 현실적으로 좀 문제가 되죠...
더구나 분산컴파일이 된다손 치더라도, 일단 각자 디버깅을 하기 위해선, 각자의 컴퓨터에서 컴파일을 해야하지요...

물론 모듈화란 말씀을 하실 수는 있지만, 그거야 그야말로 두 프로그램 그룹이 서로 독립적일 경우에 가능한 얘기입니다.
서로 빤히 알고있는 상태에서는 모듈을 나눈다고는 하지만, 필요하다면, 문제가 된다면, 다른사람이 만든 모듈을 건들어야 하게 됩니다.
또한 아무리 모듈을 잘 만들어놔두, dependency상 상위구조에 해당하는 놈을 건들게 되면, 하위구조 또한 모두다 컴파일이 되지요... 당연히 아시리라 생각합니다.

프로그램 개발중이 아니라, 리펙토링에서라면,
이러한 구조상에서 리펙토링을 쉽게 할 수가 없게됩니다.
물론 말단구조에 해당하는 부분은 리펙토링을 할 수가 있다고 하겠지만,
상위구조에 해당하는놈을 리펙토링 하다가는, 전체 시스템의 안전성을 확인하기 위해서 전체컴파일을 해야 하게 되는데...
좀 시간적으로 문제가 됩니다.
이 시간문제가 근본적으로 상위구조에서 리펙토링을 할 수 없게 만드는 가장 큰 문제가 됩니다...
쯔압..

프로젝트 크기는 따로 말씀드리지 않겠습니다.
음. 그거 확인하는것만도 시간 좀 잡히는 일이라..
^^;;

여기서부터는 좀 의미없는 논쟁이 될 듯 하군요.

저두 학생시절에 훌륭한 설계에 중요성만을 생각했습니다.
문제가 발생하게 되면, 설계를 잘못한 것이기에 소스를 고쳐야 한다는게 주된 생각이겠지만. (이와 다른 의견일수도 있구요)
여기서 프로그램 하다보니 좀 변하게되네요..
물론 설계의 중요성은 더할말이 없습니다.
하지만 그렇게 하기 힘든 경우도 많습니다.
특히 유저들과의 feedback을 하게 되는 경우에는 더욱 그러하다는것은 충분히 공감하실 듯 합니다.
물론, 개념이 꽉 잡히신 분들은, 이러한 코드를 접하기 전에는 이해하기 힘드실 듯 합니다...
저두 그랬거든요.. 와서 한동안 고생했죠...
^^;;

한번, 소스하나 수정한 다음에 컴파일타임이 1시간 이상 걸리는 문제를 리펙토링 해 보시기 바랍니다.
제대로 돌아가는지 확인하기 위해 컴파일을 하고, 실행을 하고, 다시 컴파일을 하고...
예를들어 CObject, CArchive 와 같은 계층구조를 가진 놈들을 리펙토링 한다 생각해보시기 바랍니다.
그런경우가 충분히 발생합니다.
이상과 현실은 좀 다른듯.. ^^

참고로,
.dsp 가 122개
.h 가 3500개 정도, 크기는 20~30M 입니다.
.cpp 가 3200개 정도, 크기는 50~60M 입니다.
class갯수는 좀 세기 어렵네요... struct도 있으니깐요...
소스 전체 크기는 300M정도 됩니다. 리소스 포함해서요..
그렇다고 그림등이 아주 많이 들어간것은 아닙니다.
제가알기론 이것보다 더욱 큰 프로그램도 많은걸로 알고있습니다만...
(어느사람이 VisualAssist 회사에 자신의 회사 프로젝트 크기를 알려주며 너무 커서 문제다고 올린 사람이 있었습니다. 저희와 규모가 비슷했던걸로 압니다.
VisualAssist 쪽의 대답은 그보다 10배 이상으로 훨씬 큰 규모를 가진 프로그램두 아주 많다고 대답을 했던기억이...)

컴파일은, 집에 가기전에 컴파일 합니다.
소스세이프를 통해 각자 집에가기 전에 소스를 받은 뒤, 컴파일 시켜놓고 갑니다.
다음날 아침에 새로이 작업을 하죠..
경우에따라, 귀찮은 사람들은 2~3일에 한번씩 소스세이프로 다른사람들이 업데이트 한 내용을 받습니다.. 만...

네 맞습니다.
경영진의 결단이 필요하죠. 하지만 그러기는 힘들듯 해 보입니다.
여러가지 개발일정들이 잡혀있기 때문에, 개발인원 전체에게 몇달(리펙토링을 위해선 적어도 1달 이상의 시간이 충분이 필요하리라 봅니다)의 공백기를 주고 리펙토링 하라고 할 수 없는 실정이라고 보여집니다. 그보다, 경영진(이라고 할 수는 없겠네요, 개발 상위 책임자 정도 되려나..)이 이러한 방법론을 이해하고 필요성을 느끼는게 젤 중요하죠. 하지만 그도 쉽지는 않을듯 합니다...

Large-Scale C++ 에 대한 책은, 회사사람중 한명이 이미 대강 훑어봤던걸로 알고있습니다. 결론은 굳이 적용시키려 들지 않아도 VC에서 어느정도 해결해 준다 였지요... #pragma once 가 그 대표적인 예였습니다. 그밖에 header file의 include dependency를 줄이는게 필요하지만, 아주 기본적인 수준에서의 dependency는 이후로 정리하였습니다.

아마 새로이 프로젝트를 빌드해나가게 된다면...
그때는 좀 잘 설계할 수 있을지도 모르겠습니다.
그전에 설계하는 사람들이 얼마나 잘 설계할 수 있는가 와.
앞으로 추가될 사항을 예측해서, 앞으로 일어날 수 있는 추가사항을 쉽게 반영할 수 있도록 설계하는가가 관건인거 같습니다..

ㅋㅋ
토론내용이 저로인해 엉뚱한 방향으로 흘러간거 같네요..
근데. private보다는 protected가 쓸모없지 않나요 ?

위의 손님이 쓰신 글을 보고 잠시 생각이 드는게,

같은 keyword라고 해도(예를 들어 protected) Java와 C++에서의 적용시, 의미가 다르고,
클래스 상속시, 접근자 변경의 가능 여부가 틀리고,
interface와 abstract의 조합으로 Java에서 할 수 있는 것과 C++의 virtual keyword 왜 있는지가 Java와 연관되서 이해가 된 후에

싸잡아 이 곳의 수준을 비난한 것이 아니죠?

다른 랭귀지를 쓰는 분들의 이야기를 차분히 읽어 보고 본인의 의견을 개진하길 바랍니다.

이거 솔깃한데요.
좀 더 자세한 설명과 간단한 예제로
디버깅에 밤을 새는 불쌍한 중생들을 구제해 주심이 어떨런지요

제 생각은 철학의 차이입니다.

c++ 은 어떠한 모든 구조로의 프로그램이 가능하기 위한 언어 인것 같습니다
사용자는 자신이 좋아하는 스타일로 c++프로그램을 짜면 됩니다.

상대방의 스타일에 대해 머라 하지 않을수 있도록 c++은 방대합니다.

파이썬 같은 경우엔 파이썬 언어 설계자의 프로그래밍 스타일이 언어에
그대로 드러나 있습니다. (물론 너무나도 멋지고 훌륭합니다)
파이썬 유저는 이러한 프로그래밍 스타일에 대해 고민하지 않고도
언어 자체가 유도하는 스타일의 프로그램을 할수 있습니다.

음... 주제와 조금 맞지 않나요? :oops:

사용하는 언어에 따라 접근자의 의미가 다르지만, 자바로 접근자의 의미를 풀어쓰면 다음과 같습니다. 다른 점을 이해하는데 도움이 될까 싶어 써봅니다. 그리고, 다른 언어와 비교해서 깊게 알 수가 있을까 궁금하기도 합니다.

제 경우 (Java로)에는 어떻게 하면 인터페이스를 잘 만들까, protected를 어떻게 잘 활용할까에 코딩시 신경을 많이 씁니다.

그런데, 여기에

package myDaughter; 

import myHouse.Account; 

class DaughterAccount extends Account { 
    int money = 0; // *
    void daughterWantMoney() { 
        Account newAccount = new Account(); 
        newAccount.money = 1000;  // 3) 
        DaughterAccount anotherAccount = new DaughterAccount();
        anotherAccount.money = 1000;  // 4)
    } 
} 

C++는 어떻게 됩니까?

Java에서는 상속을 할 때, 접근자를 지정할 곳이 없습니다. 제가 예시한 코드에서 public class Account를 class Account로 바꾸어 보고 DaughterAccount에서의 변화를 보면 금방 어떤 의미인지를 알 수 있습니다.

그리고, virtual keyword가 없습니다. 모든 non-static 메쏘드는 항상 dynamic binding을 사용하므로 프로그래머에게 결정할 여부가 주어지지 않습니다.

대신에, Java에서는 abstract class와 interface를 가지고 하는 것이 있는데 이건 기회가 되면 나중에 쓰도록 하죠.