니플
31k
2018-12-25 14:55:04
11
4509

[펌] OOP를 빨리 잊을 수록 여러분과 여러분의 소프트웨어에 좋습니다


https://adhrinae.github.io/posts/the-faster-you-unlearn-oop-the-better-for-you-and-your-software-kr


그저 제 경험인지는 모르겠으나, 객체 지향 프로그래밍(이하 OOP)은 소프트웨어 엔지니어링에서 표준인 것처럼 가장 많이 활용되는 패러다임으로 보입니다. 일반적으로 온라인 자료의 영향을 받은 학생들에게 그렇게 인식되기도 하고, 의도하지 않았지만 자연스럽게 OOP를 적용한 사람들 덕분에 기본적인 패러다임이라고 인식되기도 했습니다.

저도 이 개념이 얼마나 압도적으로(succumbing) 사용되는지, 그리고 표면적으로 얼마나 대단해 보이는지는 알고 있습니다. 그런 주술을 깨고 OOP가 얼마나 무시무시한지, 왜 그런지 이해하는데 몇 년의 시간이 걸렸습니다. 이러한 관점 때문에 사람들이 OOP가 왜 틀렸는지, 그리고 그 대신 무엇을 해야 하는지 이해해야 한다는 강한 믿음을 가지게 되었습니다.

많은 사람이 이전부터 OOP의 문제에 대해 갑론을박한 내용이 있고, 그중에서 제가 좋아하는 글과 비디오 링크를 마지막에 첨부하겠습니다. 그때까진 제 개인 의견을 말씀드리고자 합니다.


관심있는 분은 참고바랍니다.

3
2
  • 댓글 11

  • fender
    13k
    2018-12-25 15:26:00 작성 2018-12-25 19:20:51 수정됨

    저는 요즘 함수형 패러다임이 인기를 얻으면서 객체지향에 대한 부정적인 인식이 과장되게 퍼져나가는 경향이 있다고 생각합니다.

    링크한 글에서는 데이터 중심적 접근의 이점을 역설하고 있지만, 모든 것을 데이터와 함수로 환원 시켰을 때 과연 이전 객체지향 패러다임이 다루던 수준의 복잡성을 감당할 수 있을지에 대해선 회의적입니다.

    개인적인 느낌으로 객체지향은 구조가 복잡해질수록 장점이 부각되고 함수형은 구현의 수준으로 내려갈수록 빛을 발하는 듯 합니다. 아직까지 널리 알려진 가장 크고 복잡한 함수형 코드베이스가 대형 객체지향 코드베이스에 비해선 훨씬 단순하다는 것은 단지 이제까지 객체지향이 더 인기가 있어서만 그런 것은 아닐 것입니다.

    그렇게 본다면 객체지향이 나쁜 것이니 버리고 데이터에 집중해야 한다던가 하는 시각 보다는 어떻게 하면 객체지향과 함수형 등 다양한 패러다임을 임피던스의 불일치 없이 적절하게 조합할 수 있는지가 더 유용한 고민거리가 아닐까 싶습니다.

    예컨대 본문의 예시만 보아도 예컨대 'Player'와 'Monster' 모두 이동할 수 있거나 공격을 할 수 있는 트레잇을 공유하는 유닛이라는 계층적 정의를 유지하면서도 서로 공격을 해서 HP를 깎는 다던가 하는 상호작용 측면에선 얼마든지 함수형이나 반응형 패러다임으로 처리할 수 있는 여지가 있습니다.

    그런 관점에서 요즘 객체지향 패러다임을 구시대적 악습 쯤으로 취급하는 주장은 새로운 기술 흐름에 항상 따라다니는 '엘리티즘(elitism)'에 기인한 것이 아닌가 싶기도 합니다.

    11
  • 고고씽~
    70
    2018-12-25 20:17:54

    본인이 작성한 글이라면 자신의 실력을 다시 뒤돌아 보시길 권하고 남이 쓴글이라면 이런 글은 2000~ 2010쯤 유행하던 글이라는걸 알려드립니다.


    OOP에 대한 개념이 약할때 일부 DB주도적인 개발을 하던 측에서 나오던 주장입니다.


    이런 글을 읽고 OOP를 하기 싫어서 동조??.. 하시던 분들은 다시 책이나 동영상으로 더 열심히 공부하세요...


    자바스크립트도 객체화시키는 것을 넘어 아예 TypeScript라는 객체지향 스크립트 생성 언어를 만드는 시대입니다.


    앞으로 프런트앤드도 프런트 코어엔진 개발자와 이걸 사용하는 코더로 나뉠것입니다.


    현재처럼 프런트만 하면 커더로 머물게되니 더 깊은 수준으로 언어와 객체지향에 대해서 더욱 공부해야합니다.


    -5
  • 술술
    159
    2018-12-26 00:51:42
     뭐, 뻔한 이야기지만 프로그래밍에 정답은 없고, 함수형이든 OOP든 결국 프로젝트에 따라 적절하게 사용하면 된다고 봅니다.
     "OOP는 나쁘다" 보다는 "OOP의 오용과 이것이 최선이라는 믿음"은 경계하자는 의미에서 읽어볼 만한 거리 같습니다.
    3
  • hukk
    351
    2018-12-26 10:12:48

    제 개인적인 의견으로는 다 용도가 맞게 써야 적절하다입니다. 

    개인적인 소규모 프로젝트 개발에 자바 스프링 보다는 파이썬 장고가 더 맞듯이 

    객체, 함수 쓰는 것도 다 용도에 맞게 ~~ ^^

    2
  • 라이라
    1k
    2018-12-26 13:21:55

    사람이 이해하기에는 oo 만한게 없죠.

    0
  • 하마
    6k
    2018-12-26 13:36:18 작성 2018-12-30 13:21:26 수정됨

    내용은 너무 부실하나 OOP가 복잡함을 유발시킨다라는 것에는 일견 동감 갈 때도 있는데(그래도 오픈소스들 보면 객체지향 파이썬 혹은 자바로 짜여져 있는게  왜 가장 가독성이 좋은지 모르겠네요. 모국어라 그런건지 ㅎㅎ)  내용 중   "횡단관심사" 에서 class player 나 class monster 를  어떻게 하면 더 좋은지에 대한 "코드 예" 가 없어서 아쉽네요.

    datastore{
       player : {id,name, hp,level ...} [ ],
       monster: {id,name,hp,level} [ ],
       ....

    }

    본문글 아래쪽에 간략하게 저자가 말하듯이 이렇게 데이터구조를 만들고 (전역에서 공유되기 위한~  React 해보신 분이라면  Redux 떠오르실듯) 

    player_hit_monster(player_id, monster_id) {

         player = datastore.getplayer(player_id)
         monster = datastore.get_monster(monster_id)
         
         monster.hp -= player.power
        // monster_hp_change <- (monster,player) // 동시성의 경우  (직접 lock 을 사용 할 수도)

         ...
         ...
        // monster.hp <- done  // 동시성의 경우 

         if (monster.hp < 0){
               player.xps += monster.level
              // player_level_change <- (monster,player) // 동시성의 경우 

         }
    }

    대략 이런 함수를 만들어서 처리한다는 건가 @@?

    monster_actor {   //  golang  식의 고루틴,채널의 간략한 슈도코드. 몬스터의 상태변경은 여기서만.

          for{
                  select {
                    case (monster,player) <- monster_hp_change :
                        monster.hp -= player.power;
                        done <- monster.hp
                    case ........
                   }
           }
    }

    2
  • fender
    13k
    2018-12-26 13:41:53

    아마도 데이터 스토어 이야기는 이벤트/메시징 기반 단방향 아키텍처를 염두에두고 쓴 내용 같습니다.

    0
  • 무명소졸
    5k
    2018-12-27 08:58:08

    잘 배우고갑니다.~(댓글포함)

    0
  • Wizardeye0
    120
    2018-12-30 06:32:18
    제가 내공이 부족한가 보군요... 꽤 설득력이 있는 글 같은데 - -;;
    0
  • yeori
    534
    2018-12-30 21:21:41 작성 2018-12-30 21:25:40 수정됨

    OOP의 문제점

    * 복잡하게 만들기를 권장한다

    * 횡단 관심사(Cross-cutting concerns)

    * 객체 캡슐화는 정신 분열증이다

    * 나쁜 퍼포먼스


    그럼 대신에 뭘 해야 하나?

    * 저는 만능 해결책(silver bullet)이 있다고 생각하진 않습니다. 


    하하 ㅎㅎ 이 친구 참 ㅎㅎ


    위 글을 읽어본 감상

    OOP가 그닥 필요없는 일을 해온 사람인듯(데이터 처리 분야?)

    횡단관심사 섹션에서 Player, Monster 사례를 거론하는걸 보면 모델링을 단순한 클래스의 연결로 받아들이는게 보이네요(아니, 누가 그렇게 모델링함? ㅎㅎ)



    0
  • smilen
    16
    2018-12-31 14:57:37

    초기 윈도우 같은 GUI가 나올 때 OOP개념이 없었으면 프로그래밍이 굉장히 어려웠을 것이란 이야기가 있습니다. 

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.