Page History
...
Code Block | ||||
---|---|---|---|---|
| ||||
// 사용파트+구현파트 int main() { printf("Hello, World!"); printf("Hello, World! Again"); return 0; } |
입력을 받아 명시된 순서대로만 절차적 프로그래밍은 프로그래밍된 순서대로 처리하고 결과를 내는 방식으로 코드의 라인수대로 진행합니다.
OOP가 가진 장점중 하나인 코드의 재사용에 어려움이 있으며 명령의 재 사용을 위해 코드의 점프를 하는
프로그래밍 언어도 있습니다.
방식입니다.
구조적 프로그래밍
Code Block | ||||
---|---|---|---|---|
| ||||
//사용파트 int main() { say("Hello, World!"); say("Hello, World!"); return 0; } //구현파트 int g_sayCount = 0; void increseSayCount() { g_sayCount++; } void say(string message) { if(g_sayCount==0) hello(message) else helloAgain(message); increseSayCount(); } void hello(string message) { printf(message); } void helloAgain(string message) { printf(message + "Again"); } |
절차적 프로그래밍 방식의 개선된 형태 형태로 프로그램을 함수단위로 나누고 구조화하여 함수끼리 호출하는 방식입니다.
큰 문제를 해결하기 위해 문제를 작은 단위들로 나누어 해결하는 방식 Top-Down 방식입니다.
함수를 통한 코드의 재사용이란 장점은 어느정도 가능해졌습니다.
하지만 책임단위 구분이 없고 누가 누구를 호출할수 있는지에 대한 규칙이 없기때문에 함수가 늘어갈수록
유지보수가 어려워지는것은 동일합니다.
사용기법에 가까운 절차적 프로그래밍의 틀에 벗어나지는 못하였습니다.
객체지향 프로그래밍
Code Block | ||||
---|---|---|---|---|
| ||||
//사용파트 int main() { TalkMan talkMan= new TalkMan(); talkMan.say("Hello, World!"); talkMan.say("Hello, World!"); return 0; } //객체 정의파트 public class TalkMan { public int sayCount = 0; public void increseSayCount() { sayCount++; } public void say(string message) { if(sayCount==0) hello(message) else helloAgain(message); increseSayCount(); } public void hello(string message) { printf(message); } public void helloAgain(string message) { printf(message + "Again"); } } |
...
다소 절차적 기계어에 가까웠던 프로그래밍 해결방식을 추상화 가능하게 했다란것입니다.
추상화는 패러다임 전환관점이기도 하지만
컴퓨터 과학에서 추상화(abstraction)는 복잡한 자료, 모듈, 시스템 등으로부터 핵심적인 개념 또는 기능을 간추려 내는 것을 말한다.
-위키피디아
...
이때 동일한 기능을 다양한 방법으로 확장할수 있는것이 함수오버로딩 입니다. 기능명은 동일하지만 기능을 다양하게 동작시키는 파라메터는 방법은 여러개일수 있습니다.
Singer은 이미 말하기방식을 계승을 받았지만, 이것을 다르 방식으로 변경하여 말하는 방식을 변경하고 재정의하는것이 함수오버로딩 입니다.
나는 트로트,발라드등 다양한 장르로 노래를 부르고 싶다고~
...
Code Block | ||
---|---|---|
| ||
public class Singer: TalkMan { //............... public void sing(string message) { playText( message); } public void sing(string message,int mood) // 오보로딩을 통한 기능확장 { playText( message, mood); } public void say(string message) //오버라이딩을 통한 기능 재 정의 { sayText( message ); } //................ } |
추상화
컴퓨터 과학에서 추상화(abstraction)는 복잡한 자료, 모듈, 시스템 등으로부터 핵심적인 개념 또는 기능을 간추려 내는 것을 말한다.
추상화 클래스
다음에 설명할 추상화 Class는 이러한 특징적인 부분만을 간추려내고 이것을 상속받은 객체는 그 기능을 정의할수 있게 해줍니다.
그것을 정의를 하지 않으면 컴파일이 되지 않는 강제성을 띄게 띄지만 핵심은 강제성보다는 객체의 특징을 간추려 내는 추상화 과정에 있습니다.
말하다/노래하다를 단순하게 Voice라는 객체 특성으로 추상화로 가정하고 그것을 상속받은 객체가 구현할수 있게끔 TalkMan 을 변경해봅시다.
Code Block |
---|
abstrac Class Voice{
sayText(text);
playText(text);
} |
이 추상클래스는 보이스라는 특징적인 부분을 말하다,노래하다로 간추려내어 집합하였습니다.
보이스라는 객체자체는 존재할수 없음으로 생성이 불가능합니다.
Code Block |
---|
public Class Singer : Voice {
sayText(text){ //TODO"구현할것 };
playText(text){ //TODO"구현할것 };
} |
가수는 보이스를 가지며, 보이스는 말을할수도 있고 노래를 할수도 있습니다.
인터페이스
Code Block |
---|
abstrac Class Voice{
sayText(text) { //기능정의됨 }
playText(text) { //기능정의됨 } ;
}
abstrac Class SignLanguage{
sayText(text) { ////기능정의됨 };
} |
말하기/노래하기를 포함 수화까지 가능 한 객체로 만든다고 가정해봅시다.
Code Block |
---|
public Class Singer : Extends Voice,SignLanguage { public sayText(text) { super.sayText(text); } } |
두가지 객체를 다중상속받아 새로운 객체에 다형성을 부여하면 좋겠지만
다중상속이 허용될 경우 누가 실행될지 모르는 모호성을 가지고 있기때문에 다중상속이 제한된 언어도 있습니다.
그래서 이러한 문제를 인터페이스를 통해 추상화문제를 풀수 있게해줍니다.
Code Block |
---|
interface Voice{ sayText(text) { //기능정의됨 } playText(text) { //기능정의됨 } ; } interface SignLanguage{ sayText(text) { ////기능정의됨 }; } public Class Singer : implements Voice,SignLanguage { public sayText(text) { //새롭게 구현... } } |
추상화 클래스의 경우 구현이 포함되어 상속이 될수 있지만, 인터페이스의 경우 구현이 없고 상속보다는
기능을 가진다란 약석의 의미이기때문에 인터페이스는 다중상속이 가능합니다.
최근 모든한 언어는 인터페이스도 기능 구현에대한 정의도 가능하지만 상속이란 개념보다
그 인터페이스를 이용하는 클래스에서 상속관계와 상관없이 약속된 기능을 제공한다란 의미로 추상화가 됩니다.
Code Block |
---|
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를 만들었습니다.
평범한 자바오브젝트에 멋진 이름을 붙여줬던 시도는 기대 이상으로 성공적이었다고 합니다. 우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을
왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다.
그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고. -마틴 파울러 -