|
:: 게시판
:: 이전 게시판
|
이전 질문 게시판은 새 글 쓰기를 막았습니다. [질문 게시판]을 이용바랍니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
09/11/20 17:42
전산과는 아닙니다만... 일단 public으로 하면 class끼리 변수명 겹칠 수 있는 귀찮은 문제도 있고, 보통 객체가 가지는 속성이 public하지 않기도 하고, 그렇지 않나요? 특히 큰 프로젝트로 가면 그런 현상이 더 벌어질 듯하네요.
09/11/20 17:55
휴학생입니다만...한 객체가 다른 객체의 멤버변수에 접근할 수 있다면, 프로그래머가 의도하지 않았더라도 해당 객체가 원치 않는 결과를 내놓을 수 있습니다. 자동차 시동을 켜는 리모콘이 내 차뿐만 아니라 다른 차의 시동도 켤 수 있다고 생각해보세요. 큰일나겠죠??
09/11/20 17:58
밑에 질문글들 중에 자동차를 객체화 시켜야 된다는 글을 본거 같은데 그걸로 예를 들어 드리자면 자동차라는 커다란 프로그램에서
가장 핵심이라고 할수 있는게 엔진 부분이겠죠. 엔진을 컨트롤 할때 보통 직접 엔진을 건들이지 않습니다. 좌석에 앉아서 시동키를 넣고 엑셀을 밟아서 속도를 높이죠(차에 대해서 모르다 보니 설명은 그냥 개념적으로만 생각해 주세요.) public으로 선언해서 해당 멤버에 접근 하는건 직접 엔진을 건들이는 거고 후자에 설명한 내용이 멤버는 감춰 두고 메소드로 접근 하는 거라고 생각 하시면 됩니다. (설명하는 재주가 부족 하다 보니 적절 한지는 자신이 없네요.) 프로그램도 똑같습니다. 저 역시 개발 초짜일때 혼자서 작업 할때 저 규칙을 지키지 않고 편한 대로 짜고 그랬습니다. 하지만 공동 작업이 되면서 프로젝트의 덩치가 커지면서 저 의미들이 왜 필요 한지 깨닫게 되더군요. 여러명이 작업을 하게 되는 프로그램의 경우 가장 중요한 코어 단이 존재 합니다. 메인 프레임웍 이라고 생각 하고 여러명의 개발자들이 메인 프레임웍을 상속 받거나 아니면 그 안에서 기생 하면서 해당 기능들을 구현 합니다. 이 경우 메인 프레임웍의 멤버들이 공개가 되어 있고 마음대로 값을 바꾸는 경우에 예기치 않은 충돌들이 생깁니다. 메소드로 접근 하는 거랑 뭐가 다르냐 하시겠지만 메소드으로 접근 한다는건 멤버에 직접 접근이 아니라 간접으로 접근을 하는 겁니다. 추후에 문제가 생겼을때 예외 처리도 쉽게 가능해지고 메인프레임웍 쪽에서 제어가 가능 해지죠. 그리고 방금 떠오른걸로 메인 프레임웍에서 멤버들의 변화가 생겨야 되는 경우가 발생 할수도 있죠. 이 경우 퍼블릭으로 선언해서 여기 저기서 다 접근 해서 각각의 클래스에서 멤버변수와 동일하게 사용을 했을 경우와 멤버는 철저하게 숨기고 메소드로만 접근이 가능 하게 해서 사용이 가능 했다면.. 수정에 대한 비용은 당연히 객체지향의 개념을 따른 쪽이 절감 되죠. 프로젝트의 크기가 커지면 커질수록 이건 제곱으로 비례 한다고 생각 하시면 됩니다.
09/11/20 18:01
큰 프로그램으로 가면 다 기억을 못 합니다. 레버딘님의 리모콘 예가 참 좋은 예일 텐데요. 내 리모콘은 다른 차 시동도 켤 수 있지만 내가 조심하면 된다...라고 생각할 수도 있지만 실수할 수도 있는 거죠. 내 차랑 똑같은 차종에 색깔도 같아서 실수로 켤 수 있으니까요. 그리고 자동차들이 많아지다 보면 내 차랑 번호판까지 똑같은 차들이 생기는 일이 큰 프로젝트를 하다 보면 생깁니다. 번호판이 같은 차(=이름까지 같은 동료가 만든 함수로 예를 들면 되려나요?) 중에 내 차를 구별하기 위해 namespace라는 것으로 또 묶어서 제한하는 일도 하게 됩니다.
09/11/20 18:03
그리고 이건 여담인데.. 객체지향에 대한 개념은 어느 한 천재가 뚝딱 만들어 낸게 아니고 수십년간 쌓여온 프로그래머들의 경험이라고 생각합니다.
저 역시 그랬고 제 주변에 프로그래머들도 그랬고 초창기에는 저 개념이 이해하기도 힘들고 그냥 조심하면 되지 뭘 저렇게 시시콜콜 지키면서 코딩을 해야 되나 생각을 했지만 나중에 기초부터 확실하게 공부 해둘걸 이란 생각이 절로 들더군요.
09/11/20 18:10
대학원에가서 객체지향을 뛰어넘는 언어론같은걸 공부하실게 아니시라면 그냥 있는데로 따라만 가는방법도 굉장히 효율적입니다;;
그리고 객체의 권한같은걸 제어하는건 공동프로젝트시 혼란방지를 위해서도 굉장히 중요합니다.
09/11/20 18:55
프로그램은 어찌보면 글쓰기와 비슷합니다.
혼자서 보는 일기 같은 경우는 암호같이 써도 상관없겠지요. 남이 못 알아봐도 상관없구요. 객체 지향이나 다른 패러다임나 마찬가지지만, 일정한 철학이 없는 코드는 나중에 자기 자신도 알아보기 힘듭니다. 남이 알아보기 쉽게 하는 것도 좋은 프로그래머로서 갖추어야 할 능력입니다. 또한 그런 프레임웍과 코딩룰을 갖추고 있는 개발팀이 우수한 개발팀이지요. 실제로 저희 팀에서는 variable이나 method의 이름 조차 다른 프로그래머가 직관적으로 의도를 파악하기 힘들다면 바꿉니다.
09/11/20 19:01
성의있는 답변들 정말 감사합니다!
아직 제가 큰 프로젝트를 안해봐서 배울점도 많고 그러네요 ^^ 발전의 기회로 삼겠습니다!
09/11/20 19:42
간단한 예로 날짜 클래스가 다음과 같이 있다고 하면
class Date public int year; public int month; public int day; Date 클래스의 인스턴스를 생성한뒤 Date d = new Date(); 날짜를 지정해 줄 수 있습니다. d.year=2009; d.month=11; d.day=20; 하지만 이 방식의 경우 d.month=13; 이런 식으로 지정해주더라도 전혀 컨트롤할 방법이 없습니다. 만약 setMonth 함수등에서 적절한 처리를 해 줄 경우 이 Date 클래스의 모든 인스턴스는 반드시 '합당한' 날짜가 기록된다고 무조건 가정할 수 있습니다. 즉 세상에 존재하지 않는 날짜는 기록할 수 없음이 보장되는 것이지요. 다른 형태로 사람 클래스를 만든다고 했을때, 만약 신장이 설정되는 경우 p.setHeight(179); 그 클래스의 내부 변수에서 예를 들어서 p.type = "loser" 이런 식으로 설정되도록 setHeight 함수에서 지정해줄 수 있습니다. 따라서 이 클래스의 경우 '180미만은 무조건 type이 loser'임을 보장해 줄 수 있습니다. 일반적인 public 변수를 이용해서 자유롭게 set, get 할 경우 보장할 수 없겠지요. 일반적으로 set,get 함수는 거의 기계적으로 만들고 큰 의미가 없는 것은 사실입니다만 이러한 보장을 클래스가 해줄 수 있다는 것은 꽤 큰 의미가 있습니다. 객체지향적으로도 꽤 중요한 의미가 있습니다. 해당 클래스의 인스턴스에 이상점이 발생하지 않음이 보장된다는 것은 해당 클래스를 재사용하는 사용자들에게도 꽤 큰 의미가 있습니다. 예를 들어서 get/set이 잘 만들어진 Date 클래스를 활용하여 다른 프로그램을 만들 경우 getDate 함수등을 이용해서 날짜를 받아올 경우 이 인스턴스가 바른 날짜일지 다시 검사할 필요가 없습니다. 이미 설정될때 검사가 끝난, 그러니까 보장이 되어있으니까요. 이것은 객체지향적으로 캡슐화가 완벽히 되었다는 것을 의미하지요. 적어도 그 클래스에서 검사해야 될 것은 그 클래스가 전부 맡아서 책임 졌으니까요. 물론 더 나아가면 다른 의미도 꽤 많습니다. 객체지향적인 것과는 크게 관계 없지만, 일부 get함수들의 경우 인스턴스를 리턴하는 것이 아니라 인스턴스의 복사본을 생성해서 리턴하여 줌으로써 동기화시 발생하는 오류를 줄일 수도 있습니다. 참고로 요즘 언어들, C#이나 action script등의 경우 property라는 이름으로 약간 변형된 코드를 지원합니다. 어떤 변수에 대한 get/set 함수를 일종의 변수화된 함수로 사용하는 것인데, 예를 들어서 a.number = 100; 이런 식으로 변수 쓰듯히 호출할 경우 내부적으로 정의된 number의 set함수를 호출해서 값을 집어넣어주는 것이지요. 이것은 일종의 사용편의를 위해서 도입된 방법입니다. 사실 스크립트 언어중에서는 그냥 public 으로 변수 설정하는 경우도 꽤 많지요. (get/set 함수가 별 의미 없는 경우..)
|
||||||||||