추상화

map이라는 추상화...
reduce라는 추상화..
iterator라는 추상화..
future/promise라는 추상화...
async/await라는 추상화..
journal 이라는 추상화..
expression이라는 추상화..
vistor / Facade라는 추상화..
Traits라는 추상화..
match 라는 추상화..
executePlan이라는 추상화..
InvocationFilter라는 추상화..
Try 라는 추상화..
Composition이라는 추상화..
Channel이라는 추상화..

딱 봐도 저건 이것들을 보편화/간략화 한것이다라고 실체를 바로 판단 가능한 추상화가 있고,
대략적인 느낌 하에 세부 설명을 듣거나 해부해 봐야만, 실체에 대해 판단 가능한 추상화가 있다.

피카소의 황소그림 추상화(抽象畫) 는  전자이고, 

칸딘스키의 "즉흥"은 후자의 것이다. 

소프트웨어의 추상화(抽象化, Abstraction)는 어떤 개념들의 공통의 속성이나 기능을 묶어 이름을 붙이는 것인데,
이 것을 잘하면 먼가 대가 같아 보이긴 한다. 하지만 자동차를 움직인다고, 움직이는 것으로 추상화 하는 경우 
자동차로 명시적으로 표현하는 것보다 나을게 없을 수도 있는데 이런 경우도 많이 존재한다. 

사실 추상화는 오버엔지니어링과 구분하기 어렵다. 
치켜세워주면 유연한 설계를 한 것이고, 비판하면 시간만 잡아먹고 오히려 복잡하게 만든거 아니냐 할 수있다. 

그렇지만 나는 먼가 추상화를 하려고 노력해 놓은 코드를 보면, 어쨌거나 사랑스럽다. 
물론 GoF의 패턴에서 정의 해놓은 그 단어들은 그 책에서 나온 설계/의도대로만 사용해 줬으면 하기도 하지만, 
그 "의도"를 개인적으로 재설계해서 사용하는것을 뭐라고 하기도 참 머시기 하다...

...