객체지향 프로그래밍

객체지향(Object-Oriented Programming)을 줄여서 OOP란 표현을 더 많이하며

'Hello World' 를 찍는 예제를 통해 그 특성을 이해 해봅시다.

Let's 뎁~

절차적 프로그래밍

// 사용파트+구현파트
int main()
{
   printf("Hello, World!");
   printf("Hello, World! Again");
   return 0;
}

절차적 프로그래밍은 프로그래밍된 순서대로 처리하고 결과를 내는 방식입니다.

구조적 프로그래밍

//사용파트
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 방식입니다.

사용기법에 가까운 절차적 프로그래밍의 틀에 벗어나지는 못하였습니다.

객체지향 프로그래밍

//사용파트
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");
	}

}

큰 문제를 작게 쪼개는 것이 아니라, 작은 문제들을 해결하는 객체를 만들며 객체들을 조합해 큰 문제를 해결하는 Bottom-Up 방식으로

구조적 프로그래밍 샘플을 그대로 변환하였습니다 단순하게 구조적으로 작성된 함수를 집합을 시켰습니다.

이것만으로 OOP의 특성을 모두 이용했다고 볼수는 없지만 작은 문제를 해결하는 객체(Class)를 정의하고 집합을 시킨것으로 OOP의 시작으로 볼수 있습니다.

다음 장점이 생겨났습니다.

책임을 객체단위로 생성하고 누군가가 사용할수 있게 제공합니다.
코드의 유지보수가 객체단위로 분리될수 있으며 이후 설명될 다형성에의해 객체가 재사용되어 확장될수 있습니다.

OOP의 언어적인 특성도 있지만 중요하게 여겨봐야할것은 프로그래밍 방식의 패러다임 전환입니다.

다소 절차적 기계어에 가까웠던 프로그래밍 해결방식을 추상화 가능하게 했다란것입니다.

추상화는 패러다임 전환관점이기도 하지만

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

OOP의 4대 특성

캡슐화/상속/추상화/다형성은 OOP의 4대특성이며 , OOP로 작성된 초기버전을 변경해가며 OOP의 특성을 하나씩 알아 보겠습니다.

캡슐화

캡슐화는 다음과 같이 정의합니다. 객체의 속성(data fields)과 행위(methods)를 하나로 묶고, 실제 구현 내용 일부를 외부에 감추어 은닉한다.

OOP를 처음 배울때 은닉한다란 단어때문에 구현부 유출방지를 위한 보안적인 부분으로 생각하면 캡슐화를 이해하기가 어려워집니다.

사용부에서 관심사의 분리로 이해하는것이 더 적절할것같습니다.

외부에서 객체 내부의 데이터에 직접적으로 접근하지 못하게 하여 데이터의 안전성과 유지보수성을 높입니다.

이 약의 캡슐에 든 성분은 모르겠지만 이 약을 먹으면 투통이 나아진다고~

캡슐화중 은닉할 있는부분을 '접근제어자' 라고도하며 public → private으로 변경하면 오로지 자신의 객체 내에서만 접근이 가능하며

사용부에서 관심사를 분리할수 있습니다.

public class TalkMan { 
//...............
	private int sayCount = 0;

	private void increseSayCount()
	{
		sayCount++;
	}

    public void say(string message)
    {
        if(sayCount==0)
            hello(message)
        else
            helloAgain(message);
 
        increseSayCount();
    }
 
//................
}

talkMan.say("Hello, World!");
talkMan.say("Hello, World!");
talkMan.say("Hello, World!");
talkMan.say("Hello, World!");
이 봐 토크맨~ 나는 헬로우 월드를 찍고 싶을 뿐이야! 내가 여러번 사용하면 Again만 붙여 달라고~

상속

TalkMan을 재사용하고 'We Are The World'를 노래하는 기능으로 확장한다고 가정해봅시다.

이 코드는 기존의 이야기기능을 유지하고 새로운기능을 추가할수 있습니다.

OOP의 특성인 기존 코드의 재사용및 유지보수에 해당하는것으로 다음과 같이 이용할수 있습니다.

public class Singer: TalkMan { 
//...............
    public void sing(string message)
    {
		playText( message);
    }
 
//................
}

이봐 토크맨 나는 노래도 부를수 있다고~ 하지만 니 덕분에 나는 이야기도 할수 있다고~

다형성

노래를 할수 있는 트롯트모드.발라드 모드등 장르의 모드가 추가 되었다라고 가정해봅시다.

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

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

나는 트로트,발라드등 다양한 장르로 부르고 싶다고~

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 을 변경해봅시다.

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를 만들었습니다.
평범한 자바오브젝트에 멋진 이름을 붙여줬던 시도는 기대 이상으로 성공적이었다고 합니다. 우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을
왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다.
그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고. -마틴 파울러 -

Space Tools

객체지향 프로그래밍

절차적 프로그래밍

구조적 프로그래밍

객체지향 프로그래밍

OOP의 4대 특성

캡슐화

상속

다형성

추상화

추상화 클래스

인터페이스