디바이스 융합 자바(Java) day12 - 동적바인딩(본인우선찾기),추상클래스,추상메서드

[오늘 수업]

[동적바인딩]
예제

package class01;
class Point{
	int x;
	int y;
	void move(int x, int y) {
		this.x = x;
		this.y = y;
		System.out.println("위치변경완료!");
	}
	Point(){
		this(0,0);
	}
	Point(int x, int y){
		this.x = x;
		this.y = y;
	}
	@Override
	public String toString() { // 색도 같이 나와야 함
		return "(" + this.x + ", " + this.y + ")";
	}
}
class ColorPoint extends Point{ // 멤버변수 + 생성자 마치기
	String color;
	void move(String color, int x, int y) { // 오버로딩
		this.color = color;
		super.move(x, y);
	}
	ColorPoint(){
		this("검정", 0, 0);
	}
	ColorPoint(String color){
		this(color, 0, 0);
	}
	ColorPoint(int x, int y){
		this("검정", x, y);
	}
	ColorPoint(String color, int x, int y){
		super(x,y);
		this.color = color;
	}
	@Override
	public String toString() {
		return this.color + "(" + this.x + ", " + this.y + ")";
	}
}
public class Test01 {
	public static void main(String[] args) {
		Point[] data = new Point[5];
		data[0] = new Point(10, 20);
		data[1] = new ColorPoint();
		data[2] = new ColorPoint(10, 20);
		data[3] = new ColorPoint("빨강");
		data[4] = new ColorPoint("파랑", -1, -2);
		for(int i = 0; i < data.length; i++) {
			System.out.println(data[i].toString());
			// println은 Point를 받을 수 없는 존재...
			// 하지만 data[i].toString()는 String은 받아올 수 있어 입력 가능
			// 이때 data[i].toString()의 메서드의 출신이 Point라고뜨는데 
			// 박스가 Point박스라서 그렇다! 
		}
		// 1. 실제로 저장된 객체는 ColorPoint임에도 불구하고
		//    Point[]로 선언했기 때문에
		//    .toString()이 Point의 것이라고 안내하고 있다. ColorPoint의 func()은 못쓴다!
		// 2. 그런데! Point라고 안내해놓고 ...
		//    ColorPoint것을 호출하여 사용하고 있다?!
		// 3. 메서드를 호출해서 사용할 때 -> 자기 자신의 영역을 먼저 확인하고(특성때문에),
		//    이후의 부모 영역을 확인하기 때문!
		//    toString이 없는 상황이면! 실제 자기 영역 확인 후 부모영역 확인!
		// 4. 이 과정을 "동적 바인딩"이라고 부르며 이것 때문에 다형성이 구현,실현되었다!
	}
}

 

~ System.out.println(data[i].toString()); 에서....
       println은 Point를 받을 수 없는 존재...
       하지만 data[i].toString()는 String()을 자동 호출해서 받아올 수 있어 입력 가능
       (data[i]도 가능 - 자동 호출하기 때문에!)
       이때 data[i].toString()의 메서드의 출신이 Point라고뜨는데 
       박스가 Point박스라서 그렇다! 

 >> 정리!
       1. 실제로 저장된 객체는 ColorPoint임에도 불구하고
           Point[]로 선언했기 때문에
           .toString()이 Point의 것이라고 안내하고 있다. ColorPoint의 func()은 못쓴다!
       2. 그런데! Point라고 안내해놓고 ...
           ColorPoint것을 호출하여 사용하고 있다?!
       3. 메서드를 호출해서 사용할 때 -> 자기 자신의 영역을 먼저 확인하고,
          이후의 부모 영역을 확인하기 때문!
          toString이 없는 상황이면! 실제 자기 영역 확인 후 부모영역 확인!
       4. 자신을 먼저 찾는 이 과정을 "동적 바인딩"이라고 부르며 
          이것 때문에 다형성이 구현,실현되었다!

  예제
  동물
    소리내기() : ㅁㅁㅁ
  -> 강아지, 고양이(상속)
    소리내기() : 멍멍 -> 오버라이딩(함수 재정의)
    소리내기() : 야옹 -> 오버라이딩(함수 재정의)
  
  동물[] data = new 동물[3];
            data[i].소리내기();
            => 멍멍, 야옹이 호출
        >> 실제 객체를 먼저 참조하는 것[동적바인딩]  


사람-학생
점-색깔점
카드-신용카드,버스카드
=====================
포켓몬-피카츄,파이리
동물-강아지,고양이
모양-원,네모,세모

**이 두 모음의 차이**
사람, 점, 카드는 객체를 사용
포켓몬, 동물, 모양은 객체를 잘 사용하지 않음

원, 직사각형, 정삼각형을 배웠다!
하트를 만들어오라는 과제를 받았다!
다음으로 하는 방법
1. 구글링
   -> 이전에 작업한 프로젝트(코드) 분석
2. 코드를 카피
   원, 직사각형, 정삼각형은 하트와 동일선상에 있는데 이 도형들을
   꼭 받아와야한다는 생각한다는 것이다.
   위 도형들은 모양이라는 부모클래스가 존재
   이 모양(부모)을 받아오면 되는 것!(원, 직사각형, 정삼각형, 하트, 별 등..)(자식)
================================
[추상클래스]
   ~ 과거에 공통특성을 지닌 클래스들을 묶어서
      그들의 부모클래스를 정의하고 싶었다. ~
 **그것이 추상클래스(클래스를 묶어놓은 것)**
    ex ) 붕어빵틀들의 틀
          붕어빵을 굽는 것에는 관심 xxx
          >> 객체를 생성하지 않는다!!(생성하지 못한다!)
                 오직 관심사는 틀!!!!
          앞으로의 클래스들이 어떤 모양을 지녀야하는지에만 관심!
   그래서!!
      과거(시행차고가 있던 시절)에는, 아래에서 위로 클래스 창조하여 사용했다면
      현재에는 붕어빵틀들의 틀로써만 사용한다!
      앞으로 만들 클래스들을 정의하는데에 사용!!
  ** 객체를 생성하지 않습니다! 이 추상클래스를 받은 클래스로만 객체 생성! **
    abstract가 붙으면 객체화(instance화)불가!
    추상클래스 : 객체화, 인스턴스화 불가!!!(자기가 자기를 호출하는 것만 불가능)
    c.찍으면 내가 한 것도 가져오고 부모가 가지고있는 변수 사용 가능
    객체화만 안되는 거지 부모로서의 역할을 확실히 한다!
    객체화 외 나머지 다 작동
     >> 객체화만 안되는 거지 생성자 정의는 가능하다!! 멤버변수 초기화는 가능하다!
          자식 생성자에게 호출되기 때문이다!

   ~ 추상클래스는 객체화를 하지 못하게 강제!(프로그래머에게 아주 좋은 것)
       >> 쓸데없는 객체화를 막아줌! -> 개발자의 실수를 막아준다!

 

abstract void func1();  // 각각의 몬스터마다 고유한 액션 -> 오버라이딩해라! 라고 오더
   오버라이딩을 강제하면 안되나..? 그러면 실수 안할텐데..
   메서드 강제로 오버라이딩 하게 만들었다! -> void 앞에 abstract를 붙이면서!
    void 앞에 abstract를 붙이면서 메서드 강제로 오버라이딩 하게 만들었다!
abstract void func2(); // 추상메서드 -> 메서드 바디{}를 갖지 않는다!
    메서드바디를 붙이지 않는 이유!
    오버라이딩이 강제된 경우에는 동적바인딩에 의해 뚫고와서 부모의 것을 아예 사용할 일이 없기 때문이다
    자식 메서드만 출력될 것이기 때문에!!(가장 최근에 만들어진 것을 사용!)
         >> 자바가 아예 못쓰게 방어!!!
    추상 메서드를 한 개 이상 가지면 
    추상 메서드를 가진 클래스는 무조건 추상 클래스가 되어야 한다(abstract를 붙여야한다!)

 

package class02;
// [추상클래스]
// 객체화를 하지 못하게 "강제"!! - 프로그래머에게 아주 좋은 것이다!
// 쓸데없는 객체화 막아줌 -> 개발자의 실수 막아줌!
abstract class Shape{ // 모양이라는 클래스
	                  // 객체생성을 위해 만든 것이 아닌 앞으로 만들 클래스를 정의하기 위한 것
	int a; // 점, 선을 나타내는 멤버변수
	// 모양이면 무조건 가지는 것
	void draw() { // 모양을 그리는 함수
		System.out.println("모양그리기");
	}
	void showInfo() {
		System.out.println("모양 : " + this.a);
	}
	Shape(int a){ // 생성자 정의는 가능하다! 멤버변수 초기화는 가능하다!! 
		          // 자식 생성자에서 호출한다!!!
		this.a = a;
	}
}
class Circle extends Shape{
	int radius;
	Circle(int a, int radius){
		super(a);
		this.radius = radius;
	}
}
public class Test02 {
	public static void main(String[] args) {
		// Shape s = new Shape(); // 모양이라는 객체를 만들어쓰지 않는다..
		// abstract가 붙으면 객체화(instance화)불가!
		// 추상클래스 : 객체화, 인스턴스화 불가!!!(자기가 자기를 호출하는 것만 불가능)
		Circle c = new Circle(1, 2);
		// c.찍으면 내가 한 것도 가져오고 부모가 가지고있는 변수 사용 가능
		// 객체화만 안되는 거지 부모로서의 역할을 확실히 한다!
		// 객체화 외 나머지 다 작동
	}
}

 

------------------------------------
[추상메서드] 예시

package class02;
abstract class Po{
	abstract void func1(); // 각각의 몬스터마다 고유한 액션 -> 오버라이딩해라! 라고 오더
	// 오버라이딩을 강제하면 안되나..? 그러면 실수 안할텐데..
	// 메서드 강제로 오버라이딩 하게 만들었다! -> void 앞에 abstract를 붙이면서!
	// void 앞에 abstract를 붙이면서 메서드 강제로 오버라이딩 하게 만들었다!
	abstract void func2(); // 추상메서드 -> 메서드 바디{}를 갖지 않는다!
	// 메서드바디를 붙이지 않는 이유!
	// 오버라이딩이 강제된 경우에는 동적바인딩에 의해 뚫고와서 부모의 것을 아예 사용할 일이 없기 때문이다
	// 자식 메서드만 출력될 것이기 때문에!!(가장 최근에 만들어진 것을 사용!)
	//    >> 자바가 아예 못쓰게 방어!!!
	// 추상 메서드를 한 개 이상 가지면 
	// 추상 메서드를 가진 클래스는 무조건 추상 클래스가 되어야 한다(abstract를 붙여야한다!)
	void func3() {
		System.out.println("도망");
	}
	void func4() {
		System.out.println("밥먹기");
	}
}
class Pika extends Po{
	@Override
	void func1() {
		System.out.println("백만볼트");
	}
	@Override
	void func2() {
		System.out.println("피카츄가 방어했다!");
	}
}
public class Test03 {
	public static void main(String[] args) {
	}
}

-------
Test02의 draw()를 추상메서드로 변경!

package class02;
// [추상클래스]
// 객체화를 하지 못하게 "강제"!! - 프로그래머에게 아주 좋은 것이다!
// 쓸데없는 객체화 막아줌 -> 개발자의 실수 막아줌!
abstract class Shape{ // 모양이라는 클래스
	                  // 객체생성을 위해 만든 것이 아닌 앞으로 만들 클래스를 정의하기 위한 것
	int a; // 점, 선을 나타내는 멤버변수
	// 모양이면 무조건 가지는 것
	abstract void draw() ;
	void showInfo() {
		System.out.println("모양 : " + this.a);
	}
	Shape(int a){ // 생성자 정의는 가능하다! 멤버변수 초기화는 가능하다!! 
		          // 자식 생성자에서 호출한다!!!
		this.a = a;
	}
}
class Circle extends Shape{
	int radius;
	@Override
	void draw() {
		// TODO Auto-generated method stub
	}
	Circle(int a, int radius){
		super(a);
		this.radius = radius;
	}
}
public class Test02 {
	public static void main(String[] args) {
		// Shape s = new Shape(); // 모양이라는 객체를 만들어쓰지 않는다..
		// abstract가 붙으면 객체화(instance화)불가!
		// 추상클래스 : 객체화, 인스턴스화 불가!!!(자기가 자기를 호출하는 것만 불가능)
		Circle c = new Circle(1, 2);
		// c.찍으면 내가 한 것도 가져오고 부모가 가지고있는 변수 사용 가능
		// 객체화만 안되는 거지 부모로서의 역할을 확실히 한다!
		// 객체화 외 나머지 다 작동
	}
}

팀 프로젝트에서 가장 중요한 요소
1. 꼼꼼한 설계
2. 자세한 주석
메서드 시그니쳐(output, input) 확정
주석에 담당작업 작성

※ 메서드의 수행 주체(주어)가 누구인지 파악해야 한다!
※ 메서드의 이름 -> 카멜표기 get_score() : 웹이랑은 거리가 있는 곳
getter, setter랑 비슷하기 때문에
get이나 set이름이 앞에 들어가는 것은 잘 짓지 않는다.

OOP 특징 4가지
  1. 추상화
  2. 캡슐화
  3. 상속
  4. 다형성(override)

 

----클래스 인터페이스 사용

package class06;
// [인터페이스]
// 남들이 만든 것을 잘 가져오는 것이 중요하다!
// 실습할 때 제대로 알아보고 문법만!
// 핸드폰과 watch는 상속이 아닌데 메서드명과 시그니쳐를 강제해야할 때가 있다! 
// >> interface 사용!(new >> interface)
// 상속일때는 인터페이스를 안쓴다!! >> abstract로 거는 것이 편하다
class Phone{ 
	Watch watch;
	void soundUp(){
		watch.soundUp();
	}
}
class Watch implements usePhone{
	@Override
	public void soundUp() {
		// TODO Auto-generated method stub
	}
	@Override
	public void soundDown() {
		// TODO Auto-generated method stub
	}
	@Override
	public void Power() {
		// TODO Auto-generated method stub
	}
}
public class Test04 {
	public static void main(String[] args) {
		int a;; // 변수 3요소
		final static int b; 
		// 값을 안바꿀 생각으로 만든 상수는 반드시 초반에 초기화!
		// final int b에 대해 다시 생각
	}
}

-----인터페이스!

package class06;
public interface usePhone {
	// Phone 클래스와 연동하려는 모든 클래스들은
	// 해당 인터페이스를 구현해야만 한다!
	// 강제가 목적!!! 내부에 로직을 두지 않는다.
	public abstract void soundUp(); 
	void soundDown(); // public abstract가 숨어있다!
	void Power();
	public static final int maxSound = 100;
	int minSound = 0; // 상수 >> 값을 대입해야만 쓸 수 있다!
	// 앞에 public static final
}

>>  [인터페이스]
       남들이 만든 것을 잘 가져오는 것이 중요하다!
       실습할 때 제대로 알아보고 문법만!
       핸드폰과 watch는 상속이 아닌데 메서드명과 시그니쳐를 강제해야할 때가 있다! 
           >> interface 사용!(new >> interface)
       상속일때는 인터페이스를 안쓴다!! >> abstract로 거는 것이 편하다