미디엄 프로그래밍 섹션에 올라온 글입니다. 좋은 내용 같아서 팀원들과 공유하고 토론할 수 있도록 원글을 번역해 보았습니다. 영어 실력이 부족하다보니 번역 품질이 떨어집니다. 유념하고 읽어 주시기 바랍니다.

원글링크: https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53?source=linkShare-7e4385a4b99a-1539127342

지난 십여년간 Object Oriented 언어로 프로그래밍을 했다. 첫 OO 언어로C++를 사용했었고 그 후 스몰토크를 썼으며 마지막엔 닷넷과 자바를 썼다.

OO 패러다임을 구성하는 세 기둥인 상속(Inheritance), 캡술화(Encapsulation), 그리고 다형성(Polymorphism)이 주는 효용에 열광했다.

새롭고 흥미로운 패러다임 관점을 접한 사람들 역시 이러한 지혜를 십분 활용하여 일할것이라 믿어 의심치 않았다.

실제 오브젝트들을 클래스로 맵핑할 생각으로 흥분을 억누를 수 없었고, 모든 월드의 오브젝트들이 제대로 된 자리를 찾아 들어갈 것이라고 기대했다.

하지만, 모두 잘못된 생각이었다.

상속, 무너진 첫 기둥

상속은 OO 패러다임 중에서도 가장 큰 이점으로 여겨진다. 계층 구조를 보여주는 간단한 예제들은 모두 논리적으로 타당해 보인다.

그리고 재사용이란 단어는 매일…아니, 매년, 어쩌면 쭉 듣게되는 말이다.

나는 이 모든 것들을 받아들였고, 새롭게 깨달은 통찰과 함께 개발에 뛰어들었다.

Banana Monkey Jungle 문제

OO라는 내 마음 속 종교와 함께 문제를 풀기 위해, 클래스 계층 구조를 세우고 코드를 짜기 시작했다. 모든 것들은 문제가 없었다.

나는 원래 있던 클래스를 상속받아서 재사용 하고야 말겠다는 다짐을 잊지 않고 있었고, 마침내 그 기다리던 순간이 왔다. 새로운 프로젝트가 생겼는데 그곳에 쓸만한 클래스가 지난번 프로젝트에 있었다.

문제 없어. 재사용이 날 구해줄거야. 내가 할일은 그저 다른 프로젝트에 있는 클래스를 가져와 사용하는거 뿐이야.

어디보자…음…이 클래스만으론 안되는군. 부모 클래스가 필요하군. 이제 끝인가?

으…잠깐…부모의 부모가 또 필요해…그리고….우린 모든 부모 클래스가 필요하군. 좋아좋아, 이건 처리했어. 문제 없어!

훌륭해. 어? 왜 컴파일이 안되지? 아 알았다..이 오브젝트는 다른 오브젝트를 갖고 있군. 그 오브젝트도 넣어야겠네. 좋아, 됐다.

잠깐…난 이 오브젝트는 필요 없는데. 난 단지 이 오브젝트의 부모 클래스만 필요한데 그 부모의 부모에 포함된 모든 오브젝트들을 포함해야 하고, 또 그 부모의 부모의….

에휴.

Erlang을 만든 Joe Armstrong 이 남긴 말이 있다.

객체 지향 언어의 문제는 그들의 보이지 않는 암시적 환경까지 그들을 따라 다니는다는 것입니다. 당신이 원한건 바나나 뿐이지만 실제로 당신이 얻은건 바나나를 들고 있는 고릴라와 정글 전체였다.

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

Banana Monkey Jungle 문제 해결법

나는 상속 구조를 너무 깊게 만들지 않는 습관을 들여서 해결했다.하지만 상속이 재사용의 키라면, 상속 메카니즘에 어떠한 제약을 두는 것은 재사용의 이점을 제한하지 않을까?

그렇다면 어떤 방법이 이런 불쌍한 Object-Oriented 프로그래머를 도울 시원한 사이다가 될 수 있을까?

대리자(delegate)를 포함해서, 이 부분은 나중에 이야기해보자.

The Diamond 문제

다음 문제는 그 엉망인 모양새는 무시하고라도 다중 상속을 지원하는 언어들이라면 풀리지 않을 숙제이다.

이것이 논리적으로 타당해보일지라도, 대부분의 OO 언어들은 이것을 지원하지 않는다. OO언어로 이것을 지원하는게 어려운 이유는 무엇일까?

자, 다음의 pseudocode를 상상해보자:

Class PoweredDevice {
}

Class Scanner inherits from PoweredDevice {
  function start() {
  }
}

Class Printer inherits from PoweredDevice {
  function start() {
  }
}

Class Copier inherits from Scanner, Printer {
}

Scanner 클래스와 Printer 클래스는 start란 함수를 구현한다는 것을 상기하자.

그러면, 복사기 클래스는 어떤 시작 기능을 상속해야 할까? 스캐너 하나? 프린터 하나? 둘 다 할 순 없다.

The Diamond 문제 해결법

이것의 해결책은 간단하다. 안하면 된다.

그래, 맞다. 대부분의 OO언어는 당신이 그렇게 하도록 허락하지 않는다.

하지만…하지만…이것을 모델링 해야한다면? 난 재사용을 원한다고!!!

그렇다면 대리자(delegate)를 사용해라.

Class PoweredDevice {
}

Class Scanner inherits from PoweredDevice {
  function start() {
  }
}

Class Printer inherits from PoweredDevice {
  function start() {
  }
}

Class Copier {
  Scanner scanner
  Printer printer
  function start() {
    printer.start()
  }
}

Copier 클래스는 프린터와 스캐너 인스턴스를 포함하는 것에 유의하라. start 함수는 Printer 클래스의 구현된 start함수를 위임한다. Scanner에도 쉽게 적용할 수 있다.

이 문제는 상속이라는 기둥의 또다른 크랙이다.

The Fragile Base Class 문제

이제 나는 내 계층 구조를 얕게 만들었고 주기적으로 관리했다. 다이아몬드 구조는 없다.

그리고 이제 이 월드는 문제없었다. 아직까지는..

하루는 내 코드가 동작했고, 다음날은 멈췄다. 나는 코드를 고치지 않았는데 말이다.

어디보자….이게 버그네. 근데…뭐가 바뀌어 있는데…..

하지만 그건 내 코드가 아니었다. 내가 상속한 클래스에서 뭔가 변화가 있었다.

어떻게 베이스 클래스가 내 코드를 바꿀 수 있는가?

다음의 베이스 클래스를 보자(Java로 쓰여 있지만, Java를 모르더라도 쉽게 이해할 수 있다):

import java.util.ArrayList;
 
public class Array
{
  private ArrayList<Object> a = new ArrayList<Object>();
 
  public void add(Object element)
  {
    a.add(element);
  }
 
  public void addAll(Object elements[])
  {
    for (int i = 0; i < elements.length; ++i)
      a.add(elements[i]); // this line is going to be changed
  }
}

중요: 주석이 달린 라인을 주목하라. 이 라인이 바뀌었고 나중에 다른 코드를 깨트린다.

이 클래스는 인터페이스에 add() 와 addAll() 함수를 갖는다. add() 함수는 하나의 element를 추가하고, addAll() 함수는 다수의 elements를 add함수를 이용하여 ArrayList에 추가한다.

그리고 여기 상속받은 클래스가 있다:

public class ArrayCount extends Array
{
  private int count = 0;
 
  @Override
  public void add(Object element)
  {
    super.add(element);
    ++count;
  }
 
  @Override
  public void addAll(Object elements[])
  {
    super.addAll(elements);
    count += elements.length;
  }
}

ArrayCount클래스는 general array 클래스를 처리할 수 있게 구현되어있다. 유일한 다른 점은 ArrayCount는 elemente들의 숫자를 카운트해서 들고 있다는 것 뿐이다.

여기 두 클래스를 자세히 살펴보자.

Array의 add()는 local ArrayList에 element를 추가한다.
Array의 addAll() 은 local ArrayList의 각 element를 추가한다.

ArrayCount의 add()는 부모의 add()를 호출하고 count를 증가시킨다.
ArrayCount의 addAll() 는 부모의 addAll()를 호출하고 elements의 숫자만큼 count를 증가시킨다.

모두 잘 동작한다.

코드가 갑자기 바뀌었다. 베이스 클래스의 주석이 달렸던 라인이 다음과 같이 바뀌었다:

public void addAll(Object elements[])
  {
    for (int i = 0; i < elements.length; ++i)
      add(elements[i]); // this line was changed
  }

베이스 클래스를 소유한 클래스가 관련된 경우, 의도대로 동작한다. 그리고 모든 자동 테스트도 여전히 통과된다.

그러나 파생 클래스까지에 미치는 변화까지는 인식하지 못한다. 그리고 파생 클래스를 소유한 클래스의 경우 멍청한 계산을 하게 된다.

ArrayCount의 addAll() 는 부모의 addAll() 를 호출하고 내부적으로 자식에서 override된 add()를 호출한다.

그 결과로 count값이 자식 클래스의 add()에서 증가하게 되고 AddAll()함수에서 element들의 숫자에 따라 한번 더 더해지게 된다.

두 배로 카운트 되는 것이다.

만약 이런일이 발생하면, 모든 자식클래스를 구현한 사람들은 베이스 클래스가 어떻게 구현되었는지 알아야 한다. 그리고 그들이 예측할 수 없는 방식으로 파생 클래스를 깨트릴 수 있기 때문에 베이스 클래스의 모든 변화에 대해 알아야 한다.

에휴! 이 엄청난 크랙은 영원히 귀중한 상속이라는 기둥의 안전성을 위협할 것이다.

The Fragile Base Class 문제 해결법

다시 한번, 대리자를 클래스에 포함시키고 이것을 써서 해결하자.

대리자를 사용함으로써, 화이트 박스 프로그래밍에서 블랙 박스 프로그래밍으로 갈 수 있다. 화이트 박스 프로그래밍은 베이스 클래스의 구조를 보고 있어야만 한다.

블랙박스 프로그래밍에선 완전히 내부 구현을 몰라도 된다. 그 이유는 베이스 클래스의함수들을 overriding을 통해 삽입할 수 없기 때문이다. 인터페이스만 신경을 쓰면 된다.

이 트렌드는 좀 번거롭다…

상속은 재사용을 통해 패러다임의 승자로 여겨졌다.

OO 언어는 쉽게 대리자를 포함시키고 만들 수 없다. 이런 언어는 상속을 쉽게 하기 위해 디자인되어 있다.

당신은 나처럼 이 상속이란 기능에대해 의문을 품기 시작했을 것이다. 그러나 더욱 중요한 것은, 계층 구조를 통한 클래스 분류의 위력에 대한 믿음이 흔들린다는 것이다.

The Hierarchy Problem

새로운 회사에서 시작할때마다, 회사용 문서(e.g.직원 핸드북)를 작성할 곳을 찾기가 어려웠다.

문서라는 폴더를 만들고, 회사라는 폴더를 만듭니까?
아니면 회사라는 폴더를 만들고 문서라는 폴더를 만듭니까?

둘 다 동작한다. 하지만 어떤것이 맞는가? 어떤 것이 더 좋은가?

카테고리로 구분한 계층도(Categorical Hierarchies)의 아이디어는 기본 클래스(부모)는 좀 더 일반적이고, 이러한 속성을 갖는 클래스 들 중 몇몇 부분이 더 특화된 버전이 파생 클래스(자식)로 두는 것이다. 그리고 거기서 더욱 특화된 버전으로 체인이 이어진다. (상단의 Shape Hierarchy를 보라)

하지만 부모와 자식의 위치를 임의적으로 바꿀 수 있다면, 이 모델은 명백히 잘못된 것이다.

The Hierarchy 해결법

뭐가 잘못된 것이냐면…

계층도가 제대로 동작하지 않는 다는 것이다.

그럼 계층도는 어디에 쓸 수 있을까요?

Containment.

If you look at the real world, you’ll see Containment (or Exclusive Ownership) Hierarchies everywhere.

What you won’t find is Categorical Hierarchies. Let that sink in for a moment. The Object Oriented Paradigm was predicated upon the real world, one filled with Objects. But then it uses a broken model, viz. Categorical Hierarchies, where there is no real-world analogy.

But the real world is filled with Containment Hierarchies. A great example of a Containment Hierarchy is your socks. They are in a sock drawer which is contained in one drawer in your dresser which is contained in your bedroom which is contained in your house, etc.

Directories on your hard drive are another example of a Containment Hierarchy. They contains files.

So how do we categorize then?

Well, if you think of the Company Documents, it pretty much doesn’t matter where I put them. I can put them in a folder of Documents or a folder called Stuff.

The way I categorize it is with tags. I tag the file with the following tags:

Document
Company
Handbook

Tags have no order or hierarchy. (This solves the Diamond Problem too.)

Tags are analogous to interfaces since you can have multiple types associated with the document.

But with so many cracks, it looks like the Inheritance pillar has fallen.

Goodbye, Inheritance.

Encapsulation, the Second Pillar to Fall

At first glance, Encapsulation appears to be second biggest benefit of Object Oriented Programming.

Object state variables are protected from outside access, i.e. they’re Encapsulated in the Object.

No longer will we have to worry about global variables that are being accessed by who-knows-who.

Encapsulation is a Safe for your variables.

This Encapsulation thing is INCREDIBLE!!

Long live Encapsulation…

That is until…

The Reference Problem

For efficiency sake, Objects are passed to functions NOT by their value but by reference.

What that means is that functions will not pass the Object, but instead pass a reference or pointer to the Object.

If an Object is passed by reference to an Object Constructor, the constructor can put that Object reference in a private variable which is protected by Encapsulation.

But the passed Object is NOT safe!

Why not? Because some other piece of code has a pointer to the Object, viz. the code that called the Constructor. It MUST have a reference to the Object otherwise it couldn’t pass it to the Constructor?

The Reference Solution

The Constructor will have to Clone the passed in Object. And not a shallow clone but a deep clone, i.e. every object that is contained in the passed in Object and every object in those objects and so on and so on.

So much for efficiency.

And here’s the kicker. Not all objects can be Cloned. Some have Operating System resources associated with them making cloning useless at best or at worst impossible.

And EVERY single mainstream OO language has this problem.

Goodbye, Encapsulation.

Polymorphism, the Third Pillar to Fall

Polymorphism was the redheaded stepchild of the Object Oriented Trinity.

It’s sort of the Larry Fine of the group.

Everywhere they went he was there, but he was just a supporting character.

It’s not that Polymorphism isn’t great, it’s just that you don’t need an Object Oriented language to get this.

Interfaces will give you this. And without all of the baggage of OO.

And with Interfaces, there isn’t a limit to how many different behaviors you can mix in.

So without much ado, we say goodbye to OO Polymorphism and hello to interface-based Polymorphism.

Broken Promises

Well, OO sure promised a lot in the early days. And these promises are still being made to naive programmers sitting in classrooms, reading blogs and taking online courses.

It’s taken me years to realize how OO lied to me. I too was wide-eyed and inexperienced and trusting.

And I got burned.

Good-bye, Object Oriented Programming.

So then what?

Hello, Functional Programming. It’s been so nice to work with you over the past few years.

Just so you know, I’m NOT taking any of your promises at face value. I’m going to have to see it to believe it.

Once burned, twice shy and all.

You understand.

If you liked this, click the💚 below so other people will see this here on Medium.

If you want to join a community of web developers learning and helping each other to develop web apps using Functional Programming in Elm please check out my Facebook Group, Learn Elm Programminghttps://www.facebook.com/groups/learnelm/

My Twitter: @cscalfani