데비앙의 블로그

abstract class와 interface는 비슷하지만 다르다.

공통점, 차이점, 용도에 대해 알아보자~

​

​

​

1. 공통점

​

abstract class(추상 클래스)와 interface 는 선언만 있고 구현 내용이 없는 클래스이다.

​

그래서 자기 자신이 new를 해서 객체를 생성할 수 없으며,

추상클래스를 extends 받거나, interface를 implements 한 자식만이 객체를 생성할 수 있다.

상속받은 자식이 구현을 반드시 하도록 해야할 때 사용한다.

​

JAVA에서는 type이 지정되있기 때문에 선언된 type과 자식의 type이 같아야만 한다.

​

​

​

2. 차이점

​

추상클래스는 말그대로 클래스이고, interface는 구현하기 전에 메소드에 대해 명세된 것이랄까?

그래서 상속을 받음에도 불구하고 클래스에선 상속이라고 쓰지만 interface는 implemets(구현) 이라고 쓴다.

​

추상클래스의 정의는 abstract 메소드가 하나라도 존재하는 클래스를 일컫는다.

때문에 일부는 구현된 메소드도 있고, abstract라고 붙어있는 메소드는 구현이 안되어있다.

​

추상클래스를 상속받는 클래스는 반드시 추상메소드를 구현해야한다.

그래서 필수적으로 구현해야할 메소드가 있을 때 추상클래스를 쓰게된다.

​

​

인터페이스는 구현체 없이, 메소드에 대한 명세만 되어있다.

인터페이스를 상속받는 클래스에서는 반드시 인터페이스에 있는 메소드를 다 구현해야한다.

​

자바는 단일상속을 지원하기 때문에 추상클래스는 단일상속이지만,

interface를 사용하게 되면, implements를 구현하는 부분에서 extends 또한 사용할 수 있다.

즉, 다중상속이 가능해진다.

​

​

'이러이러한 메소드를 쓸 것이다.' 인터페이스에 선언을 해놓고, 가져다가 반드시 선언된 그대로 모두 구현하면 되는게 인터페이스이고,

​

이러이러한 메소드가 있지만 가져다 쓰거나 오버라이드 하거나, abstract가 붙은 메소드는 반드시 구현하면 되는게 abstract class이다.

​

​

​

3. 용도

​

책을 아무리 읽고 인터넷을 찾아봐도 이해가 잘 안가는

추상클래스와 인터페이스의 용도!

​

그나마 조금 알게된 용도를 정리한다 ㅎㅎ

​

​

​

인터페이스를 설명하려면 다형성(Polymorphism)에 대한 개념이 등장한다.

다형성이라고 하면 어려울 것 같지만 아래같이 생각하면 쉬울 것이다.

​

​

​

​

동물들은 모두 먹고, 걷는다.

하지만 동물들마다 먹고 걷는 방식은 다르다.

​

구현체에서는 동물 각각이 먹고 걷는 방식을 구현한다.

같은 '먹는다'라는 동사에서, 동물마다 여러가지 형태로 구현할 수 있기때문에 이름이 다형성.

​

​

​

그렇다면 인터페이스를 쓰면 얻는 이득이 무엇인가?

​

동물이 먹고, 걷고, 자는 것은 공통적인데, 그 것을 행하는 방법이 각자 다르다.

고양이는 걸을 때 네발로 걷고, 원숭이는 두발 또는 네발로, 병아리도 두발로..

​

그래서 동물이 먹고, 걷고, 잔다는 틀만 만들어놓고

고양이, 원숭이, 병아리는 그 틀안에 자신만의 방법으로 메소드를 구현하는 것이다.

​

반드시 구현체 동물들은 먹고 걷고 자는방법이 구현되어야 한다. 동물이라면..

그리고 고양이의 자는법이 달라져도 원숭이, 병아리에게는 아무 영향도 없다.

​

​

​

그럼 추상화 클래스는 언제 쓰는게 좋은가?

​

​

야생고양이가 새끼를 낳았다.

새끼는 인간에 의해 집고양이가 되었다고하자.

​

​

​

좀 억지이지만 ㅋㅋㅋ

​

어미고양이는 야생고양이므로,

집에서 사는법은 모르지만, 새끼고양이는 집에서 사는법을 알려주기 위해 추상화 메소드로 만들었다.(구현X)

​

어미고양이는 자는법이 있었고, 자식에게 전수하였다.

그러나 자식은 집고양이라 어미고양이와 자는법이 달랐다.

​

그래서 자식고양이 나름대로 자는법을 새로 터득하였다.

그게 이미 구현되어있는 부모클래스의 내용을 Override를 하는 것이다.

​

새끼고양이는 집 생활을 하며, 어미고양이가 모르는, 집에 사는법을 더 많이 터득하였다.

(부모 클래스보다 더 많이 구현되는 경우가 대부분이다)

​

​

​

그니깐 총정리를 하면,

인터페이스는 다형성이라 생각하면되고,

​

상속은 부모 - 자식 관계..

부모가 갖고있는 기능을 유전 받으면서, 기능을 더 추가한다거나,

부모의 유전된 기능을 약간 수정할 때 쓴다.

1 Ibatis에서 MyBatis로 변경된 이유

Apache project팀에서 google code팀으로 이동하면서 명칭이 변경됨.

2 차이점

2.1 Java 요구 버전

iBatis에서는 JDK 1.4 이상에서 사용 가능 MyBatis에서는 JDK 1.5 이상 사용 가능.

2.2 패키지 내부 구조가 변경되었음.

ibatis : com.ibatis.*

MyBatis : org.apache.ibatis.*

2.3 sqlMap.xml 내부 구조가 변경되었음.

parameterMap 사용 못함. -> parameterType으로 대체.

dtd가 변경 (“http://mybatis.org/dtd/mybatis-3-mapper.dtd”>

사용 용어의 변경

2.4 MyBatis lib 별도 제공

Maven Dependency Information 예시

<dependency>

<groupId>org.mybatis</groupId>

<artifactId>mybatis</artifactId>

<version>3.2.2</version>

</dependency>

<dependency>

<groupId>org.mybatis</groupId>

<artifactId>mybatis-spring</artifactId>

<version>1.2.0</version>

</dependency>

2.5 Annotation 도입

sqlMapClient DI 설정 불필요

간편해짐

Bean id sqlSesstionFactory, sqlSesstionTemplate만 지정하면 됨.

2.6 rowHandler 대체

xml및 대량 데이터 처리를 위해 사용되었던 rowHandler가 삭제

rowHandler -> resulthandler로 변경됨

자바 annotation을 사용하여 xml을 사용하지 않고 자바로만 할 수 있게 됨.

자바 선언 보다 xml 선언이 우선순위를 가짐.

2.7 네임스페이스 방식 변경

ibatis : <sqlMap namespace=”User”>

MyBatis : <mapper namespace=”myBatis.mapper.UserMapper”>

네임스페이스 사용은 필수, userStatementNameSpace설정 제거

2.8 동적 SQL – XML 엘리먼트

If, choose(when, otherwise), trim (whre,set), foreach

2.9 동적 SQL – Provider annotation

@SelectProvider(type=CommentSqlProvider.class, method=”selectCommentByCondition”)

2.10 캐시 지원.

2.11 (스프링 연동모듈) mapper 자동 검색

​

3 변경되거나 추가된 속성들 (종합)