Please Enable JavaScript!
Mohon Aktifkan Javascript![ Enable JavaScript ]

객체지향 _ 객체, 클래스, 인스턴스

2010. 5. 19. 16:33programming/terms

728x90
객체지향이라는 패러다임

객체지향이라는 패러다임은 세계를 인식하는 새로운 방법, 즉, 철학이나 인식론의 차원에서 다루어져야 한다고 생각합니다. 디자인의 방법이나 프로그래밍의 스타일로 접근할 때, 수박겉핥기, 혹은 숲은 무시하고 나무만 보기라는 오류에 빠지기 쉽다는 주장입니다.

코딩하는 일에 익숙한 프로그래머나 해커들에게는 고통스러운 일이지만, 객체지향을 논의할 때는 잠시 컴퓨터와 컴퓨터 언어를 잊고 현실세계를 바라보는 것이 좋은 방법입니다. C++나 자바, 스몰톡 등의 특정 언어에 몰두하기 시작하면 객체지향으로 가는 길은 갈수록 멀어집니다. 어셈블리어로도 객체지향 프로그래밍을 할 수 있다는 사실은 모두 아시고 계실 겁니다.

쉬운 예를 들기 위해서 구조적 인식과 객체지향적 인식의 차이를 비교해 보도록 하겠습니다. 예를 들어 어떤 남자가 애인과의 약속을 정한다고 했을 때, 구조적 인식은 다음과 같이 분석을 할 것입니다.

남자는 애인과 약속을 정하기 위한 방법을 선택한다. 전화, 이메일, 편지 등의 방법중에서 전화를 선택한 남자는 전화를 찾기 위해서 주변을 둘러본다. 현재 자신은 길거리에 있으며, 핸드폰이 있는가 확인해 보니 핸드폰은 없고 전화카드가 있다. 그래서 가까운 공중전화를 검색한 후에 애인의 전화번호를 찾아서 공중전화를 건다. 만일 애인이 전화를 받으면 약속시간을 정하고, 애인이 전화를 받지 않으면 적당한 시간을 기다렸다가 전화를 한다. 애인이 전화를 받을 때까지 이 과정을 계속한다.

그러나 객체지향적 인식은 다음과 같이 분석을 하게 될 것입니다.

남자라는 객체와 여자라는 객체가 있다. 이 두 객체는 사람이라는 객체의 상속을 받을 것이며, 사람이라는 객체는 전화번호라는 속성을 가지고 있고, 전화를 건다.라는 메소드와 전화를 받는다.라는 메소드가 있다. 마찬가지로 핸드폰, 공중전화, 전화카드라는 객체가 정의될 수 있으며, 사람이라는 객체는 핸드폰이나 전화카드를 소유할 수 있다. 남자가 애인에게 전화를 거는 과정은 남자라는 객체의 한 인스턴스가 자신의 애인 속성의 객체로 포함된 인스턴스에게 전화를 건다.라는 메소드를 실행시키는 것이고, 여자라는 객체의 한 인스턴스가 남자 인스턴스로부터 전화를 받는다.라는 메소드를 통해 메시지를 전달받는 과정이다.

위의 두가지 인식법에서 알 수 있듯이 객체지향이라는 패러다임은 실세계를 어떻게 인식하고 그것을 어떻게 디자인하고 프로그래밍을 하고 코딩을 할 것인가?하는 문제라고 볼 수 있습니다.

객체지향의 개념
객체지향이라는 패러다임을 지원하는 데에는 몇가지의 개념이 요구됩니다. 여기에서는 그러한 개념들에 대해서 간단하게 정의하도록 하겠습니다.

객체, 클래스, 인스턴스

객체란 실세계에 존재하는 모든 개체들입니다. 좀 더 광범위하게 말하자면 모든 것은 객체로 표현할 수 있다는 것을 의미합니다. 클래스는 이러한 객체의 형태를 정의하고, 객체를 만들어 내기 위한 형틀입니다. 클래스로 만들어 낸 하나의 개체로서 존재하는 객체를 인스턴스라 합니다.

비유적으로 표현하자면, 붕어빵은 객체입니다. 밀가루와 단팥을 가지고 있는 붕어모양의 맛있는 빵입니다. 프로그래머는 붕어빵 객체를 만들기 위해 붕어빵의 속성과 반죽합니다. 붓는다. 불에 굽는다. 등의 메소드를 가진 붕어빵 틀을 클래스로 정의하였습니다. 그래서 그 클래스를 통해 붕어빵 열 개를 구웠습니다. 즉, 열 개의 인스턴스를 만들었습다.(좀 엉성한 비유... -_-)

정보 보호(Information Hiding)

객체는 속성과 메소드를 가집니다. 속성은 그 객체의 성질을 설명하는 데이터이며, 메소드는 그 객체에게 메시지를 전달하거나 어떤 동작을 요구하기 위한 인터페이스입니다. 이런 속성과 메소드를 객체를 구성할 때 한꺼번에 묶은 후 외부로부터 보호할 수 있습니다. 이것을 캡슐화(Encapsulation)라고도 합니다.

상속성(Inheritance)

실세계에서는 여러 객체들의 공통적인 특성을 합친 보다 일반적인 다른 객체로 표현될 수 있습니다. 클래스도 일반적인 클래스에 독특한 속성과 메소드를 추가하여 새로운 클래스를 정의할 수 있습니다. 이것을 상속한다고 하고, 상속을 하는 클래스를 서브클래스, 상속을 받는 클래스를 수퍼클래스라고 합니다.

예를 들어, 동물이라는 수퍼클래스는 조류, 포유류, 파충류 등의 서브클래스를 가질 수 있습니다. 포유류라는 수퍼클래스는 사자, 호랑이, 토끼, 개 등의 서브클래스를 가질 수 있습니다. 개라는 수퍼클래스는 치와와, 불독, 진돗개, 똥개 등의 서브클래스를 가질 수 있습니다.

다형성(Polymorphism)

다형성이란 같은 이름의 메소드나 연산자가 여러 가지의 기능을 할 수 있음을 의미합니다. 오버로딩이나 오버라이딩이 다형성의 한 예입니다. 오버로딩은 같은 클래스 내에서 같은 이름을 가진 메소드가 다른 인자를 가질 수 있음을 의미하고, 오버라이딩은 상속관계에 있는 클래스에서 같은 이름과 같은 인자를 가지고 서로 다른 일을 하는 메소드를 가질 수 있음을 의미합니다.

자바에서의 객체지향
자바는 객체지향 언어입니다. 그러므로 앞에서 말한 객체지향 개념을 대부분 포함하고 있습니다. 여기서 '대부분'이라고 말하는 것은 자바가 객체지향 개념들을 모두 지원하지는 않는다는 의미입니다.

자바는 간단하고 단순한 언어를 목표로 설계되었습니다. 따라서 C/C++에서의 포인터와 같은 어려운 내용은 모두 삭제하였으며, 객체지향 개념중에서도 복잡하고 어려운 내용은 모두 삭제하고 꼭 필요한 기능만 제공하거나 쉽게 적용할 수 있도록 변형을 가했습니다.

다음은 자바에서의 객체지향 개념들 중에서 주목할 만한 몇가지들입니다.

자바에서의 다중상속

자바에서는 다중상속을 지원하지 않는다. 대신 인터페이스를 지원함으로써 다중상속을 사용할 수 있도록 하였다. 인터페이스는 클래스와 동일하지만, 실제로 구현은 할 수 없고 다만 상속하기 위해서 사용하는 클래스라고 볼 수 있다.

class A extends B implements C, D, E {
// some body
}

위의 코드는 B 클래스와 C, D, E 인터페이스를 상속하는 A 클래스를 정의한다.

자바에서의 오버로딩

자바는 오버로딩을 지원하지 않는다. 유일한 예외는 + 연산자의 String 객체에 대한 연산자 오버로딩이다. 자바는 오버로딩을 지원하지 않는 대신, 메소드를 메소드 이름과 인자의 개수, 형, 순서를 조합하여 식별함으로써, 메소드 오버로딩과 동일한 효과를 낼 수 있도록 하였다.

즉, insert(int a)와 insert(float a)는 인수의 형이 다르므로 서로 다른 메소드로 정의하고 사용할 수 있다.

자바에서의 접근 제어

자바는 public, protected, friendly, private 라는 네 단계의 접근 제어자를 지원함으로써 멤버 변수와 메소드에 대한 서로 다른 접근 권한을 부여할 수 있다. friendly는 접근 제어자를 아무 것도 지정해 주지 않았을 때의 접근 제어를 의미한다.

public은 모든 객체가 접근할 수 있으며, protected는 같은 패키지 내의 모든 객체가 접근할 수 있고, 상속을 받은 객체들이 사용할 수 있다. private는 자기 자신 외에는 어떤 객체도 사용할 수 없으며, friendly는 같은 패키지 내의 모든 객체가 접근할 수 있다.

객체의 생성과 소멸

자바에서 객체는 생성자를 통해 생성된다. 그러나 소멸자는 지원하지 않는다. 사용되지 않는 메모리는 가비지 컬렉션에 의해 자동적으로 수집된다. 프로그래머는 더 이상 소멸자를 통해 메모리의 해제에 신경을 쓸 필요가 없다. 이것은 프로그래머의 부담을 덜어준다. 가비지 컬렉터는 우선순위가 낮은 시스템 쓰레드로서, 더 이상 사용되지 않는 메모리를 자동적으로 시스템에 돌려주는 역할을 한다.

728x90

'programming > terms' 카테고리의 다른 글

객체 지향 프로그램( Object-oriented programming)  (0) 2010.06.22
자바 charAt(0)  (0) 2010.03.30
서블릿(Servlet)  (0) 2010.03.26
지역 변수 와 멤버 변수  (0) 2010.03.25
오버플로우(Overflow)  (0) 2010.03.25