OOP의 이론중 하나가 함수나, 객체를 최대한 작게 쪼개라는 거잖아? 그렇게 하면 더 재사용에 용이하다고 하는데...
예를들어 이런 함수가 있다고 치자.
BigFunc()
{
...수천라인의 코드
}
그런데 한 함수안에 이렇게 많은 줄의 코드가 있는건 함수/객체를 최대한 작은 단위까지 쪼개야 한다는 OOP 이론에 위배돼. 그래서
BigFunc()
{
SmallFunc1();
SmallFunc2();
SmallFunc3();
}
이런식으로 쪼개는게 이론적으론 옳은건데, 과연 현실적으로도 옳을까?
이렇게 쪼갠 함수를, 과연 다른곳에서 재사용 하는게 가능하긴 할까?
다른데에서 SmallFunc2를 호출할때의 프로그램의 상태가, BigFunc에서 SmallFunc2를 호출할때의 상태가 같을확률은 극히 적고, 그러면 잘 작동이 될리가 없지.
그래서 같은 코드의 재사용을 해야하는 상황이 오기 전에, 미리 코드를 더 작은 단위로 쪼개버리는건 개인적으로 아니라고 생각함.
글쓰는 실력이 안좋아서 제대로 설명을 못하겠네... 나도 코세님처럼 글 잘쓰고싶당
수천 라인이 되는 함수 안에 의미가 없는 코드들의 조각들로 채워진 경우는 드물거에요 : )
의미가 있다면 그 의미를 따서 인라인 함수를 뽑으시면 됩니다. 성능 건들지 않고 주석이 덜 필요해지죠. 읽기도 편안하고.
글은 써버릇하면 느는것 : ) 많이 써 주세유~
codesafer//거에요->거예요 (받침 있으면 이에요 없으면 예요 이로 끝나면 받침 없으므로 예요 요 떼서 말 되면 에요 아니에요는 예외 인명엔 예요(예 : 길동이예요) 성까지 쓰면 이에요(예 : 홍길동이에요)) [리듬 맞춤법 봇♬]
ㄴ 가독성을 위해 인라이닝하는건 괜찮다고 생각해요
ㄴ 하지만 가독성을 위해서라면 그 함수의 scope 내에서만 정의하는걸로 충분할텐데 C++에선 람다, 즉 local scope함수를 인라이닝하는게 지원이 되지 않아 좀 아쉽긴 해요.
그게 가독성만의 문제가 아니라, 스코프 밖에서 재사용할 가능성을 높여주죠.
의미롭다는건 보다 일반적인 의미에 다가갈수 있다는 뜻이기도 합니다. 작게 나눌수록 일반적이구요.
소인수분해랑 같은이치죠. 두 문제를 풀기위한 최소공배수를 구하기 쉽게 되고, 그것들 스스로가 다른 문제의 소인수가 됩니다.
그렇다면 다른 소스에서 재사용을 해야할 상황이 왔을때 그 함수를 파일 또는 글로벌 스코프로 확장 시키는게 맞는것 같아요. 그 상황이 오기 전까지는 local scope로 남겨두고요. 그런데 이렇게 재사용이 가능한 함수도 상당히 적지 않을까요... side effect가 적은 함수에 가까울수록 재사용성이 높고, 글로벌 상태(변수나 리소스같은)를 변경할 가능성이 있는 함수같은 것들은 재사용을 하기엔 상당히 위험하다고 생각합니다
그니까 그냥 잘게 쪼개는게 아니고 재사용 가능하면서 제네릭 하도록 쪼개라는 거지. 어떻게? 로직을 일반화 시키고 파라미터로 특수화 시키면 됨.
그렇죠... 다만 그런걸 고려하지 않고 무조건 잘게 쪼개는게 흔히 알려져 있는 OOP의 이론 중 하나이고, 그게 실제로 제대로 적용이 되진 않는다는걸 말하고 싶었을 뿐이에여
저는 따로 OOP 에 대한 책을 읽지 않았고, 내 고집대로 실제 케이스에서 유용한 형태로만 짜왔지만, 자연히 이론으로 수렴되더군요.
간접적으로 접하게 되는 대부분의 책들의 내용은 진지하게 고찰하고 실용성 있는 예제를 담기보다 다분 이론을 겉도는 형태를 갖고 있더군요. 그래서 사람들이 클린코드는 실무에서 적용하기 어렵다는 선입견을 갖게 되는듯 해요.
물론 코드 열심히 깎아 일반화할 개발 기간이 부족한 탓도 있겠습니다만, 그게 습관이 되면 십수년이 지나도 코딩스타일이 변하지 않게되죠.
그렇다 보니 십수년간의 작업들에서 다시 쓸만한 건질 코드가 없게 되는것이구요.
조금씩 조금씩 더 훈련해 나가고 코드를 일반화해서 깎아나가는 습관을 들이면, 점점 다시사용할 수 있는 코드들도 풍성해지고, 편협한 논리나, 논리적인 중복들도 효과적으로 제거해 나갈 수 있으리라 생각합니다.
네... 좋은 말씀 감사합니다
실제 케이스에서 유용한 형태가, 실제로 유용한거겠죠... 이론적으로 유용하다고 주장해봐야 써먹을 수 없으면 아무 소용 없으니까요
정말 잘 짜면 이론에 수렴합니다 : ) 이론이 특별한건 없거든요.
가장 작게 쪼개면 뭐겠어요. 기본 연산자죠. 재사용성이 아주 훌륭하잖아요? : ) 본질은 변하지 않습니다.
아무리 상속하고, 연산자들을 모아 좀더 큰 함수를 만들고, 큰 함수를 모아 더 큰 함수와 큰 구조를 갖게 되어도 말이죠. 알맹이의 본질은 변하지 않습니다.
양자가 상호작용하는 최소의 단위인 것 처럼, 거대한 양자들의 집합인 사람들도 상호작용을 하고 있듯 말이죠.
이 글은 예전에 OOP관련 책들 막 찾아보다가 (디자인 패턴, 이펙티브 C++시리즈, 프로페셔널 C++ 등등등...) 실제로 코드를 짜니 책에서 본거랑은 또 차이가 있어서 깨달았던 점 중 하나였어요. 마치 어떤 문제를 풀어야 되는지도 모른채 해결책(어떤 문제에 대한건지도 모르는)만 찾아다니는 경우를 경험해봤고, 주위에도 그런 케이스가 꽤 많아요. 심지어 몇몇 교수님들도 그런식으로 가르치는 경우도 많고...
전에 누가추천해서 힐링캠프를 봤는데,
법륜스님인가 하는 분이 그러더군요. 불법의 진리를 깨치는건 몇 달이면 충분히 가능한 일이다.
하지만, 그 사람이 깨달음을 얻고 세상으로 내려가면, 다시 금방 흐트러지고 만다.
책에 있는 내용을 막 이해한 상태에서 자신에게 주어진 문제에 적용하려고 해 봐도 쉬운 일은 아닙니다.
사람은 흔히, 이해하지 못한 것을 이해했다고 믿고, 충분히 알 수 있는 사실을 너무 어렵다고 착각하는 동물이거든요.
악보읽는법 배우고 피아노 친다고, 피아노 교사가 시킨 앉은 자세나, 운지법이 아~ 이게 정말 유용하구나 하고 느끼게 되는건 아니듯,
뭐든 숙성이 필요합니다. 그렇다고 불편해서 삐딱한 자세로 되는데로 손가락 놀리면, 난이도 있는 곡을 연주할 순 없죠. 달달 외운 몇 곡만 가능할 뿐이지.
되는대로.
일반화가 되기 위해선, 울퉁불퉁하게 내 안에 들어온 앎이, 동글동글해질때까지 다듬는 작업이 필요합니다.
네. 악보를 읽을줄 몰랐던 비틀즈도 훌륭한 명반을 만들어내고, 실용음악학원이 존재하지 않던 과거에도 대단한 아티스트와 명곡이 나왔듯... 이론은 무언가 충분히 경험한 후에 배워도 늦지 않다고 생각합니다
앉는
뭐 어디서 부터 출발하든 사필귀정입니다.
재밌게 코딩하면 되죠.
하나 주의하실 것은, 예술과 공학의 차이입니다.
평생이 걸려 정말 멋진 코드 하나를 만들 수 있을지 없을지 모르는게 예술적 접근이구요.
여러 도구들을 이용해, 이미 논리적으로 검증된 많은 지적 도구들을 활용하는게 공학입니다.
전자는 완벽주의고 끝이없고, 후자는 상대적으로 저렴한시간 내에 끝이나는 완성주의에 해당하죠.
제 경험상, 본인이 정말 하늘이 선택한 극소수라고 생각하는 사람이 아니라면, 여러 사람들이 만들어 놓은 논리적 틀을 외면하기 보다, 왜 잘 안되는지 무엇이 문제인지, 스스로를 반성해나가는게 시간을 절약하는 접근일 것 같습니다.
네... 모든 이론을 배제한 채로 바닥부터 생각하는것은 당연히 옳지 않다고 생각합니다. 논리적으로 검증된 이론은 실제 경험으로부터 나왔을테니까요. 단지 모든 이론이 검증이 된것은 아니라고도 생각합니다(실제로 사람들이 그것들이 검증이 되었다고 생각할지라도). 검증된 이론만 쏙쏙 골라배울수 있는 능력이 있으면 좋겠는데, 그러려면 기본적인 실력이 받쳐줘야 될테고... 복잡하네요ㅎㅎ
많은걸 배울수 있는 대화여서 좋았습니다ㅎㅎ
둘이 섹스해
나는 재사용이 불가능하더라도 여러조각으로 쪼개는걸 선호함. 한번 완성한 코드는 나혼자쓰는게 아니고 너무 긴 메소드들은 가독성을 너무해치거든