행복하자!!
338
2022-05-14 12:20:52
2
752

추상화를 이럴때는 좀 안쓰는게 좋지않나요??(궁금해서 물어봅니다 요즘 추상화 배우고 있는데 다른분들 의견이 궁금합니다.)


okky에서도 추상화에 대한 여러글을 봤는데 의견이 항상 갈리는거 같아 좀 정리 좀 하고자 글을 올려 봅니다.


추상화를 쓰면 생기는 단점


1. 구현체를 런타임시 결정


2. 소스만 봐서는 추상화된 타입만 보고 구현체를 찾기 힘들다. 런타임이 아닌 이상.(구현체가 조건에 따라 바뀔수도 있어서 디버깅 힘듬)


3. 추상화 했던 서비스가 바뀔 시에 구현체들을 모두 바꿔줘야 한다.




사용 측면에서 추상화 타입을 통한 쉬운 구현체 변경과  확장을 위해서

추상화를 미리 시켜서 코드를 읽기 힘들게하는 위에 문제점들을 가질 필요가 있나 싶습니다.


 

추상화가 필요한 작업은

1. 미사일이나 군사 시설 등 틀리면 안되는 중요한 프로그램일 떄 객체 자체에 행위들에 강제성을 주고

일관성을 갖는데 의미를 두는것도 같습니다.


2. 설계단에서 동일한 역할을 하는 구현체가 많다 싶을 떄 또는 개발이 다 끝난 시점에 필요한 추상화를 하는것이 좋다고 생각이 됩니다.

3.외부로 라이브러리를 오픈하는 경우나(디비 커넥션 처럼)



다른분들 의견이 궁금합니다.


0
  • 댓글 2

  • yeori
    3k
    2022-05-15 07:59:27

    추상화는 인간의 인지 능력에 한계가 있어서 자연히 발생합니다. 프로그래밍에서의 추상화뿐만아니라 일상 생활 전반에서 인간은 추상화된 환경에서 살아갑니다.

    코드를 읽어내려가다보면 갑자기 구현체가 드러나지 않는 인터페이스가 등장할때가 있습니다.

    코드를 들여다보려는 관성에 제동이 걸리고, 갑자기 뭔가 막혔다는 느낌이 듭니다. 브레이크 포인트를 걸고 디버깅을 돌려서 구현체를 찾기도 하죠.

    코드를 들여다보는 도중에 갑자기 인터페이스가 등장하면 바로 그 지점이 "지금 전개되는" 코드의 맥락과 동떨어진 지점입니다. 거기서 더 깊이 들어가면 인지 부하가 높아져 코드의 맥락을 이해하는데 방해가 될 수 있는, 이세계로 빠지는 길입니다.

    문자열 다룰때 s.substring(2, 8)과같은 메소드를 쓰면서 내부 동작까지 다 이해하려고 애쓰지 않아도 되듯이 현재 전개되는 코드 맥락과 직접적인 관계가 없는 기능들은 적절한 추상화로 격리시켜야 합니다.

    메소드나 함수를 따로 정의하는 것도 그 본질은 추상화입니다. 반복되는 동작을 호출해서 쓰자는 기능적인 목적도 있지만 인지적으로는 지금 구현하려는 문제 맥락과 직접적인 연관이 없기때문에 함수로 따로 빼내서 인지 부하를 낮추려는겁니다.

    "아침에 알람이 안울려서 급하게 택시를 탔는데 신호가 너무 막히길래 도중에 내려서 지하철을 타고 왔다"라고 늦은 이유를 설명할때도 프로그래밍과 똑같이 수많은 추상화가 존재합니다.

    알람이 울리는 기계적 메커니즘, 택시가 움직이는 원리, 교통 신호 조절의 과정, 티머니 카드의 금액이 차감되는 원리 등등 수많은 사건들이 얽혀있으나 적절한 용어들로(알람, 택시승차, 결제, 교통 신호) 추상화시켜서 대화의 맥락을 간결하게 유지합니다. 이런 것들이 프로그래밍에서는 함수나 클래스 인터페이스, 패키지 등에 해당합니다.

    인간이 이해할 수 있는 범위는 정해져있고, 대개는 범위가 넓지 않습니다. 그래서 추상화는 인간의 습성이 된듯하고 프로그래밍도 예외는 아닙니다.

    그래서 결론은 "적응해야함"

  • 행복하자!!
    338
    2022-05-15 13:48:45

    댓글을 읽으면서 생각 흐름 정리가 잘됐습니다.!!


    생각의 흐름을 애기하자면


    추상화에 대한 필요성이 조직에서도 나타나는거 같습니다.


    예를들면 대통령이 굳이 행정, 경호, 법 전문가들 보다 많이 알  필요 없이 이 사람들이 무슨 일을 하고 내가 그 사람들한테 무엇을 기대하는지만 명확하게 안다면 그걸로 충분한거져


    yeori님이 달아주신 인지능력과 매우 연관된 애기 입니다!! 어차피 한 사람이 다 통달하는건 무리이니까용



    하지만 추상화의 고질적인 문제점도 결국은 껴안고 가게 됩니다..

    우리은행 600억 횡령 사태도 결국 추상화로 조직관리를 하다보니 조직 내부에 디테일 까지 파악못하여

    발생한 일이라고 생각되서 항상 단점을 염두해두고 프로그래밍 해야할 거 같습니다..

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