Java(심화) - 객체 지향 프로그래밍

 

안녕하세요

 

Shiny Ocean 입니다 : )

 

이번 포스팅에서 다루어볼 내용은 객체지향프로그래밍입니다.

 

 

본문

 

OOP, Object Oriented Programming, 부품 객체를 먼저 만들고 이것들을 하나씩 조립해서 완성된 프로그램을 만드는 기법입니다. 이때 부품으로 사용되는 각각의 객체들은 속성과 동작으로 구성됩니다, 이를 필드와 메소드라 합니다. 하나의 객체내에 반드시 메소드가 존재하여야 하는것은 아니지만 필드값은 존재하여야 합니다.

 

예를 들어 간단한 사칙연산을 하는 프로그램예제를 다루어보겠습니다. 

public class Exam {

	 public static void main(String[] args) {
		 
		 int a = 1;
		 int b = 2;
		 
		 int result = 0;
		 
		 result = a + b;
//		 result = a - b;
//		 result = a * b;
//		 result = a / b;
		 
		 System.out.println(result);
		 

  }
}

 

절차적으로 코딩한다면 위와 같습니다. 메인 클래스의 메인메소드 내에서 전체 코드 로직을 쭉쭉 써내려갑니다. 이러한 코드가 결코 나쁘다는 뜻은 아닙니다. 코딩 자체가 쓰레드를 분기하거나 프로세스를 하나 포크하지 않는이상 절차적 흐름과 컴파일로 결과가 만들어지니 절차를 무시해서는 안됩니다.

 

그러나, 라인이 길어지고 로직이 복잡해지면, 이는 부품으로 나누는게 필요할것입니다. 그렇게 해야 오류를 파악하거나 수정하는것이 편하고 가독성도 늘어나기 때문입니다.

 

사칙연산을 부품으로 나누면 어떨까요? 

사칙연산의 대상이될 두개의 숫자, [더하기,빼기,나누기,곱하기]의 동작등으로 나누면 될것 같습니다.

 

이를위해 클래스를 짜고 필드와 메소드를 만들어 봐야 할것 같습니다. 그럼 아래와 같습니다.

 

class CalcAB{
	int a;
	int b;
	public CalcAB(int a, int b) {
		this.a =a;
		this.b =b;
		
	}
	
	public int add() {
		return a+b;
	}
	public int sub() {
		return a-b;
	}
	public int mul() {
		return a*b;
	}
	public int div() {
		return a/b;
	}
	
}

public class Exam {

	 public static void main(String[] args) {
		 
		 int a = 1;
		 int b = 2;
		 
		 CalcAB AB = new CalcAB(a, b);
		 
		 System.out.println(AB.add());
		 
		 
		 

  }
}

 

이렇게 한다면 장점이 무엇일까요?

 

제가 생각하기에는 메인 로직이 조금 더 눈으로 보기에 논리적이라는 것입니다. 이를 위해 메소드 명이나 객체의 이름등을 많이 신경써서 선언해주어야 하지만 한번 선언한 객체는 재사용이가능하기 때문에 효율이 좋습니다.

 

이러한 방법으로 부품을 나누고 필요할때 하나하나 조립하여 사용하는것이 객체지향적인 프로그래밍입니다.

 

이 부품들 즉 객체들은 서로 상호작용을 하며 이는 크게 세가지 관계를 같습니다.

 

1. 집합관계 : 완성품과 부품의 관계

2. 사용관계 : 객체가 다른 객체를 사용하는 관계

3. 상속관계 : 종류 객체와 구체적인 사물 객체의 관계

 

(출처 : 이것이 자바다 - 한빛미디어)

 

캡슐화

캡슐화 : 객체의 필드, 메소드를 하나로 묶고, 실제 구현 내용은 외부에 감추는 것을 말한다.

캡슐로 된 감기약을 먹는다 치겠습니다.

우리는 감기에 걸려 의사에게 처방받은 해당 알약이 감기에 효과적이라는 사실을 알고있습니다. 하지만 그안에 어떤 성분이 들어있고, 어떻게 우리몸에서 동작해서 감기가 나을수있고 ,어떻게 만들어지는지 등 모르는거 투성입니다.

 

하지만! 우리가 그거까지 알고 캡슐약을 먹어야 합니까?

아닙니다. 그건 캡슐약을 만드는 사람이나 알면되는 것입니다. 우리는 당장 감기에만 효과가 있으면 장땡이죠

프로그래밍에서도 비슷합니다. 전체적으로 좀 궤변같지만 캡슐약에 노출된 효과나 모양이 외부객체인 사람에겐 보이지만 숨긴 데이터나 메소드는 모르듯이 필요에 의해 객체의 모든 요소들에 대해 이런 캡슐화를 진행합니다.

 

이러한 요소들은 외부에 의해 읽기와 쓰기가 가능한 것들이있고 이를 제한하는 이유는 객체 본연의 의미를 잃지 않기 위해서 입니다. 만약 맥도날드에가서 서브웨이 허니오트로 햄버거를 만들어 달라하면 그게 맥도날드 햄버거일까요? 아니겠죠! 그러니 맥도날드 객체는 빵이라는 요소를 남이 접근할수 없도록 제한할것입니다.

 

이러한 작업을 자바에서는 접근 제한자를 이용하여 처리합니다. 많이 써본 public, private 등입니다!

 

상속

흔히 재벌들이 자식들에게 재산상속을 하죠, 비슷합니다. 돈은 변하지 않은 채로 물려주지만 이를 어떻게 불릴지는 자식의 몫입니다. 물론 돈의 경우 도박으로 잃을수도 있지만 객체의 상속은 사라지는 경우는 없습니다.

궤변을 바탕으로 코딩을 해봅시다. 

package exma;

class Parent{
	protected final int 유산 = 10000;
	
	public void flex유산() {
		System.out.println(유산);
	}
}

class Child extends Parent {
	private final int 내돈 = 1000;
	public void flex내돈() {
		System.out.println(내돈);
	}
	
	public void flex재산() {
		System.out.println(내돈 + 유산);
	}
	
	
}

public class Exam {

	 public static void main(String[] args) {
		 
		 Child 재벌2세 = new Child();
		 
		 재벌2세.flex내돈();
		 재벌2세.flex유산();
		 재벌2세.flex재산();
		 

  }
}

 

위의 코드의 주인공 재벌은 부모의 유산을 상속받아 내돈과 합쳐 재산을 만들었습니다.

부러워요... 실제로 Parant객체를 상속받은거말고 Child객체가 유산에 대하여 한게 없습니다. 하지만 상속받아서 현실세계(메인메소드)에서 신나게 flex 할수 있죠... 물론 본인 클래스 내에서도 flex할수 있습니다. 음침한 재벌이라면 돈과 관련된 속성들은 모두 접근을 제한해서 본인 클래스에서만 볼수있게도 하겠네요 위에서 다룬 캡슐화를 이용해서 말이죠!

 

 

다형성

마지막으로 다루어볼 객체 지향의 특성은 다형성입니다. 

같은 타입이지만 실행결과가 다양한 객체를 대입할수 있는 성질을 말합니다. 부모 타입에는 모든 자식 객체가 대입되고 인터페이스 타입에는 모든 구현객체가 대입됩니다. 효과로 객체를 부품화 시킬 수 있고, 유지보수가 용이합니다.

 

인터페이스 구현체를 어떻게 구현하냐에 따라 그 결과가 다양해질수 있다는것이 핵심일것 같습니다.

이전에 추상메소드와 관련된 게시글을 작성한적이 있는데 그쪽이 이 다형성을 설명하는데 더 알맞을것 같습니다.

 

 

 

+@

최근 가장 많이 느끼는 것은 객체와 관련된 이름의 선언인것 같습니다. 객체지향적으로 열심히 코드를 작성해 나가는데 이름이 별로면 사용하기도 별로입니다.

 

만약 로봇을 만드는데 부품으로 열심히 로봇팔을 만들었다 치겠습니다.

근데 이름을 원숭이팔로 지었다하면 조립하는 과정에서 로봇에 원숭이팔을 붙이는 일이 생깁니다. 코딩은 열심히 했고 분기도 열심히했다해도 이런식으로 이름하나 잘못지으면 망합니다....

객체명을 잘못정하면 위와 같고 변수명이나 메소드명을 잘못지어도 끔찍합니다.

 

최악의 경우 몇시간 열심히 작성한 객체를 메인문과 연결할때 엉뚱한 이름때문에 뭘 만들었는지도 까먹습니다.

이 경우을 위의 상황에 대입하면,

로봇을 만들때 로봇팔을 찾아 붙여야되는데 만들어둔 로봇팔 이름이 원숭이팔이라서 헷갈려서 못붙이는 일이 발생합니다. 그럼 다시 로봇팔을 만들고.... 가재팔이라 이름짓고.. 또까먹고... ㅋㅋ

 

제 이야기입니다... 앞으론 안그래야죠...

 

열심히 만든 부품들 우리의 클래스와 메소드, 필드에 이름도 열심히 붙여줍시당!!