posts/the-faster-you-unlearn-oop-the-better-for-you-and-your-software-kr

[utterances-bot]

[번역] OOP를 빨리 잊을 수록 여러분과 여러분의 소프트웨어에 좋습니다 | rinae's devlog

OOP를 향한 신랄한 비판(?) 번역 (not about functional programming) - 비판적으로 읽어주세요

https://rinae.dev/posts/the-faster-you-unlearn-oop-the-better-for-you-and-your-software-kr

[teahyuk]

음... OOP자체가 나쁘다고 보진 않습니다.
나쁜건 위에 설명하셨다 시피
목표 -> 데이터 설계(구조) -> 코드 를 제대로 따르지 않는 개발자의 책임이 크겠지요,
OOP가 잘못 한 것이라고 본다면 클래스 설계를 강조해 쉽게 개발자가 데이터(도메인 설계) 이전에 클래스설계 부터 가게 한 것이 잘못이라고 보면 보는게 맞을까요.

하지만 비즈니스를 진행하다보면 아무리 단단하게 만들더라도 데이터구조 부터도 여러가지 이슈로 인해서 변경되게 마련입니다.

그렇게 된다면, 데이터 설계를 한 뒤에 그 데이터 설계에 유연하지 못하게 클래스 설계를 한 해당 OOP 개발자의 잘못이 크겠지요, (역량 차이라고 합시다.)

제 개인적인 의견이지만 저는 OOP는 상태 중심 지향이 아닌 행동 지향 적인 개발 방식이라고 생각합니다. 데이터는 (상태) 를 갖고 있는 정보 자체? 구요.

다른 분들도 그렇게 생각하는 사람들이 많아서인지, 클래스 내부에서의 필드들은 private으로 감추고 굳이 게터와 세터를 만드는 등의 구조들이 나온 것 같기도 하구요.

하지만 그런 의미에서 게터와 세터를 들고있는, 흔히 말하는 VO 라고 하는 상태 핸들링을 목표로 하는 Class들은 OOP의 지향점을 정면으로 반박하는, (제가 생각하는 지향점을 해치는, OOP가 아닌) 구조라고 여겨집니다.

맞지 않는 옷을 억지로 끼워 넣은 듯한 느낌이랄 까요, 마치 java8의 functionInterface같은 느낌이죠..

그런의미에서 오히려 C++에서의 struct를 사용하는 것도 (이부분은 OOP관점 설계가 아닌 데이터다!) 라고 하고 개발하는 방향도 좋지 않을 까 싶기도 하구요.

그런 의미에서 위에서 설명한 예제들은 VO설계의 허점, (데이터를 유연하게 대처하기 힘들게 하는 개발자의 행태?)에 관한 고찰이 될 만한 것 같네요.

페이스북에 올라온 어그로 성 글이 시작이라고 하는거 같긴 하지만 어쨋든 다시한번 생각 하는 계기가 되는것 같아서 좋네요.

데이터(도메인 설계) 관점에서, 예전에 읽었던 DDD관련 책자들을 다시 한번 꺼내봐야 겠군요.

[adhrinae]

@teahyuk 의견 감사합니다. 저도 OOP라는걸 더 이해해보고 싶은 한낱 무지렁이에 불과합니다. 단순히 글 내용에 전반적으로 공감해서 글을 번역하고 알렸다기 보다, 이렇게 OOP 자체에 대한 생각과 의견들을 나누고 싶어서 번역을 진행해 보았습니다. 막상 글을 공유하고 나니 원문의 내용 자체가 생각보다 부실하다고 느끼고 있어서 아쉽지만요.

OOP는 '행동 지향적인 개발 방식이라고 생각한다' 는 말씀에 공감이 가네요.
C++의 struct 언급하신것도 결국 잡다한 역할을 갖는 클래스보다 POJO가 언급되고 있는 이유랑 비슷하겠다는 생각도 듭니다.

어떤 방법론으로 개발하더라도 요즘은 데이터 중심 사고가 많이 언급된다고 생각합니다. 그 데이터를 어떻게 유연하게 다루고, 확장성있는 프로그램을 만드느냐가 되겠죠.

[dbwodlf3]

저는 Java를 처음 할 때. 그 징글징글한 모습에 질려버렸죠.
하지만 경험이 쌓이면서 지금 다시 와서 생각해보면 Java는 처음 개발하는 사람의 입장에서 배우기 조금 어려운 언어였던 것 같아요.
OOP를 OOP답게 사용하지 않는다면 그건 이것도 저것도 뭣도 아닌 괴상한 것이니까요...

적당한 량의 OOP. 적당한 량의 추상화..
적당적당...

[adhrinae]

@dbwodlf3 그렇죠. 그 적당히를 잘 하기 위해 공부를 하는게 아닌가 하고 생각하게 됩니다 :)

[skt-t1-byungi]

내용은 공감하는데 결론이 "그래서 oop는 나쁘다"는 잘못됐다고 생각하네요.

저는 클래스를 하나 만드는게 하나의 레이어(네트워크 통신에서 물리계층, 전송계층. 응용계층 같은)를 추가하는 일이라고 봅니다. 이 레이어는 자신이 소유한 컨텍스트의 복잡성을 낮추고 레이어 사이에 유연성을 만듭니다. 그러나 레이어가 많을 수록 오버헤드가 발생합니다. 이웃 레이어가 장벽이 되서 목적을 이루기 위한 가장 효율적인 방법 대신 여러번의 간접적인 우회를 통해 비효율적으로 프로그램이 수행되고 있을 수 있습니다. 불필요한 레이어는 복잡성을 되려 높이기도 하구요. 이 글에서 말하는 그래프, 복잡성,나쁜퍼포먼스(인다이렉션)등이 그러한 점을 지적하는거라고 생각합니다.

네트워크처럼 가장 퍼포먼스에 신경써야할 영역에서 조차 7개나 되는 레이어를 두듯이 우리가 작성하는 프로그램도 복잡성을 낮추고 유연성을 얻기 위해서는 레이어가 반드시 필요합니다. OOP는 이것에 대한 가장 성숙하고 발달된 방법론이구요.

음 그러나 제가 이글에 공감하기도 하는 부분이기도 한데요, 제가 본 많은 사람들이 이 레이어(클래스를 작성하는)를 부족하게 만들기 보다는, 너무 쉽게 쉽게 많이 만드는 경향이 있는것 같습니다. 얘기를 나눠보면 지금 필요 없더라도 레이어를 잘게 잘게 많이, 그리고 멋진 이름을 붙이는 것을 노련한 개발자라고 인식하는 것 같습니다.

또 딱 필요한 만큼의 레이어를 만들기 위해서는 이글의 저자 말씀처럼 구현전 설계가 중요하고 깊은 고민이 필요한데요. 많은 분들이 설계에 에너지를 쏟고 구현하는(워터폴 같은) 방식 대신에 점진적으로 고치고 나아가는 방법을 선호하는 것 같습니다. 하지만 최초 플랜이 엉망이면 점진적인 방법으로는 컴팩트한 레이어가 만들어지지 않을 가능성이 높습니다.

얘기가 길어졌지만... 제게는 공감이 가는(결론은 동의할수 없지만) 글이었습니다. 번역감사합니다.

[adhrinae]

@skt-t1-byungi

음 그러나 제가 이글에 공감하기도 하는 부분이기도 한데요, 제가 본 많은 사람들이 이 레이어(클래스를 작성하는)를 부족하게 만들기 보다는, 너무 쉽게 쉽게 많이 만드는 경향이 있는것 같습니다. 얘기를 나눠보면 지금 필요 없더라도 레이어를 잘게 잘게 많이, 그리고 멋진 이름을 붙이는 것을 노련한 개발자라고 인식하는 것 같습니다.

말씀 남겨주신 부분이 저도 비슷하게 공감됩니다. 글 시작과 끝에서 여러번 강조하긴 했지만, 저도 이 글에 부분적으로 공감이 되는 부분만 있을 뿐이고 다른 분들의 더 깊은 생각을 듣고 싶다는 생각으로 번역 및 공유를 했습니다.

그래서 간만에 병기님 의견 남겨주신게 많은 도움이 되었습니다. 고맙습니다.

[kdw9502]

좋은 글 잘 읽었습니다.

[hamtol2]

원문을 읽던 중에 읽기 쉽게 번역이 된 페이지를 찾았네요.
설계 시점에 신중한 고민 없이 적당히 타협한 후에 클래스 선언을 남발하고 있는 저를 반성하게끔하는 다소 충격적인 글이네요. 전체적으로 다 이해가 되지 않는 부분도 있고, 공감하는 부분도 있지만, 제가 진행하는 프로젝트에 바로 적용하려고 하니 어떻게 해야할지 감이 오지 않네요.
많은 고민을 하게끔 하는 글인것 같습니다.

좋은 글 번역해주셔서 감사합니다.

[adhrinae]

@hamtol2 잘 읽어주셨다니 기쁩니다. 제가 추신으로 달아두었던 비판 의견과 함께 봐주시면 더 좋고요. 이 글은 "유효한" 글이지만 "유용한" 글은 아니라고 생각하고 있습니다. 다만, 고민하신대로 "내가 잘 설계를 하고 있는가?" 하는 경각심을 심어줄 수는 있겠지요. 나머지는 더 나은 설계를 위해 OOP든 그 외의 패러다임/방법론이든 공부 및 경험을 쌓아나가는게 중요하리라 봅니다.

[Cloud9Bumsu]

목표 -> 데이터 설계(구조) -> 코드 좋은 말씀이네요. 좋은 글 잘읽었습니다.

[cjunekim]

그다지 동의가 안되는 글이네요. 의도는 알겠습니다. 얼빠진 상태로 만드는(mindless) OOP를 비판하는 것 같습니다. 난해한 저 글 읽는 것보다 데이비드 파르나스의 1972년도 논문을 읽는 것을(심지어 누구처럼 일년에 한번씩 읽는 것을) 권합니다.

제가 월간 마소에 2003년 4월부터 연재했던 "고전을 찾아서"시리즈 네번째 글을 보세요. 모듈화와 정보은닉의 상관관계 : 많이 알면 다친다 (고전을 찾아서 4편), 마소 2003년 7월호. "On the Criteria To Be Used in Decomposing Systems into Modules"

[adhrinae]

@cjunekim 자료 추천 감사합니다. 저 역시 의도만 적당히 캐치한 정도이고 그다지 동의하는 글도 아닙니다만, 이 글을 통해 많은 분들이 추가로 익혀두면 좋은 정보를 공유해주셔서 결과적으로 도움이 된다고 생각합니다.

말씀해주신 월간 마소 과월호는 지금 마이크로소프트웨어쪽도 재고가 없는 것으로 알고 있어서, 언급해주신 논문 원몬이라도 도움이 되겠습니다.
원 논문 링크

혹시 과월호 기사를 직접 접할 수 있는 웹 문서 링크를 알려주신다면 더 큰 도움이 되겠습니다.