Page History

...

이때 동일한 기능을 다양한 방법으로 확장할수 있는것이 함수오버로딩 입니다. 기능명은 동일하지만 기능을 다양하게 동작시키는 파라메터는 방법은 여러개일수 있습니다.

Singer은 이미 말하기방식을 계승을 받았지만, 이것을 다르 방식으로 변경하여 말하는 방식을 변경하고 재정의하는것이 함수오버로딩 입니다.

...

컴퓨터 과학에서 추상화(abstraction)는 복잡한 자료, 모듈, 시스템 등으로부터 핵심적인 개념 또는 기능을 간추려 내는 것을 말한다.

추상화 클래스

다음에 설명할 추상화 Class는 이러한 특징적인 부분만을  간추려내고 이것을 상속받은 객체는 그 기능을 정의할수 있게 해줍니다.

그것을 정의를 하지 않으면 컴파일이 되지 않는 강제성을 띄게 띄지만 핵심은 강제성보다는 객체의 특징을 간추려 내는 추상화 과정에 있습니다.

말하다/노래하다를 단순하게 Voice라는 객체 특성으로 추상화로 가정하고  그것을 상속받은 객체가 구현할수 있게끔 TalkMan 을 변경해봅시다.

abstrac Class Voice{
  sayText(text);
  playText(text);  
}

이 추상클래스는 보이스라는 특징적인 부분을 말하다,노래하다로 간추려내어 집합하였습니다.

보이스라는 객체자체는 존재할수 없음으로 생성이 불가능합니다.

public Class Singer : Voice {
  sayText(text){ //TODO"구현할것 };
  playText(text){ //TODO"구현할것 };
}

가수는 보이스를 가지며, 보이스는 말을할수도 있고 노래를 할수도 있습니다.

인터페이스

abstrac Class Voice{
  sayText(text) { //기능정의됨 }
  playText(text) { //기능정의됨 } ;  
}

abstrac Class SignLanguage{
  sayText(text) { ////기능정의됨 }; 
}

말하기/노래하기를 포함 수화까지 가능 한 객체로 만든다고 가정해봅시다.

public Class Singer : Extends Voice,SignLanguage {

  public sayText(text) { super.sayText(text);  }

}

두가지 객체를 다중상속받아 새로운 객체에 다형성을 부여하면 좋겠지만

다중상속이 허용될 경우 누가 실행될지 모르는 모호성을 가지고 있기때문에 다중상속이 제한된 언어도 있습니다.

그래서 이러한 문제를 인터페이스를 통해 추상화문제를 풀수 있게해줍니다.

interface Voice{
  sayText(text) { //기능정의됨 }
  playText(text) { //기능정의됨 } ;  
}

interface SignLanguage{
  sayText(text) { ////기능정의됨 }; 
}

public Class Singer : implements  Voice,SignLanguage {

  public sayText(text) { //새롭게 구현...  }

}

추상화 클래스의 경우 구현이 포함되어 상속이 될수 있지만, 인터페이스의 경우 구현이 없고 상속보다는 

기능을 가진다란 약석의 의미이기때문에  인터페이스는 다중상속이 가능합니다.

최근 모든한 언어는 인터페이스도 기능 구현에대한 정의도 가능하지만 상속이란 개념보다

그 인터페이스를 이용하는 클래스에서 상속관계와 상관없이 약속된 기능을 제공한다란 의미로 추상화가 됩니다.

public class Voice{
  sayText(text) { //기능정의됨 }
  playText(text) { //기능정의됨 } ;  
}

public class SignLanguage{
  sayText(text) { ////기능정의됨 }; 
}

public Class Talker  {

  public Voice voice;
  public SignLanguage voice;

}

다중으로 상속이 여려울경우 다양한 객체자체를 다중으로 가질수 있는 전략을 선택할수도 있습니다.

마치며

...

OOP를 지원하는 언어에서 OOP의 대표적인 4대(캡슐화,상속,추상화,다형성) 특성에 대한 이용방법및 제약이 약간다를수 있습니다.

문법적으로 4가지 특성을 모두 잘 활용하는 것만이 OOP가 아닌 설계단위및 문제해결 방법을 우리가 현실세계에서 이해하고 이용할수 있는

추상화가 가능한 절차적 해결방법에서의 패러다임 전환이 가장 중요한 요소인듯 보여집니다.

OOP가 EJB와같은 기술때문에 상실이 되었던 시기에, POJO라는 단어로 인해 다시 OOP로 돌아가게되는 게기가 되었습니다.

마틴 파울러는 자바의 단순한 오브젝트를 이용하여 로직을 구현하는게 나은데 왜 EJB처럼 복잡하고 제한 많은 기술을 이용할까? 라는 의문이 들었습니다.

마틴은 그저 그럴싸한 이름이 없는게 원인 일까 싶어  POJO를 만들었습니다.

평범한 자바오브젝트에 멋진 이름을 붙여줬던 시도는 기대 이상으로 성공적이었다고 합니다. 우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을

왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다.

그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고. -마틴 파울러 -