회사내에서 한 사원이 가지고 있는 OO 기본 책을 보면서 다시금 Object(이하 오브젝트)와 Class(이하 클래스)의 차이점에 대해 생각해 보았다. 학부때 배웠던 이야기 이지만, 다시 잊지 않기 위해 정리해 본다.
잘못된 개념의 시작
Java의 유행이 시작되던 2000년대 초반, 우리는 클래스와 오브젝트의 개념을 붕어빵과 빵틀이라는 잘못된 예로 배워왔다. 빵틀에서 재료를 넣고 쿵 찍어내면 붕어빵이 나오듯 클래스를 이용해 오브젝트를 만들어 낸다고 배워왔던 것이다. 이것은 Java(OOP)에서 클래스를 설명하기 위해 가장 쉬운 방법이자 잘못된 개념을 습득하기 가장 쉬운 방법이었다.
오브젝트 타입
오브젝트와 클래스 관계는 사실 오브젝트 타입이라는 우리가 간과하는 개념이 숨어 있는데, 오브젝트와 클래스를 설명하기 위해선 것을 놓치지 말아야 한다. 보통 그냥 타입이라고도 일컬어 지는 오브젝트 타입은 무엇일까?
오브젝트는 정보를 가진 Attribute(이하 속성)과 정보를 가지고 행동을 할 수 있는 Behavior(이하 행동)을 가진다. 하나의 객체가 생성되는 이유는 하나의 목적을 취하기 위함이다. 어떤 사람이 집에서 중간 경유지를 들러 목적지에 도착하는 것과 같다. 사람이 목적지로 가기 위해 선택할 수 있는 몇가지 방법들이 있는데 이것이 타입이다. 즉, 하나의 목적을 가진 오브젝트들의 행동패턴들의 집합을 오브젝트 타입이라고 한다.
클래스
그럼 클래스는 무엇일까? 앞에서 이야기한 오브젝트 타입과는 무엇이 다른까? 클래스는 사전적 의미로 공통 성질을 가진 종류라고 정의한다. 타입은 어떠한 형태를 의미한다. 타입이 클래스 보다 엄격한 의미를 지닌다. 결론적으로(개인적인 의견이다), 클래스라는 용어를 사용하며 우리는 보다 유연하게 또는 느슨하게 사용할 수 있다.
즉, 우리가 프로그래밍을 할 때 머릿속의 개념은 오브젝트 타입이 될 것이고, 이것으로 그대로 구현한 것은 클래스이다. 다시말해서 설계는 오브젝트 타입으로 하고, 구현은 클래스로 한다. 그리고, 시스템은 클래스를 인스턴스화 한다. 그럼 인스턴스는? 인스턴스의 사전적 의미는 보기, 사례이다. 클래스에 담겨 있는 어떠한 성질의 사례라는 의미로 이해하면 되겠다.
정리
오브젝트, 오브젝트 타입, 클래스, 인스턴스에 대하여 알아보았다. 정리하자면, 머릿속에 떠다니는 개념상의 용어로 오브젝트와 오브젝트 타입이 쓰이고, 이것들의 구현체가 클래스와 인스턴스 라고 생각하면 되겠다.
어찌보면 작은 용어의 차이지만, 알고 사용하는 것과 모르고 사용하는 것의 차이는 크다. 또, 잘못된 용어의 선택은 큰 재앙을 가져오는 경우가 많기 때문이다.
JPA에서 데이터를 수정, 삭제하는 방법은 크게 두가지로 나뉠수 있다. 첫째로 JPA에서 제공하는 EntityManager를 사용하는 방법. 그리고, JPQL에서 UPDATE, DELETE를 실행하는 방법. 여기서 이야기 하고자 하는 것은 JPQL에서 UPDATE, DELETE 하는 방법이다. (bulk update / delete 라고 한다.)
@PersistenceContext em;
JPQL을 이용하여 데이터를 DELETE 하는 방법은 쉽다. 아래 소스를 참고하자.
. . .
// start transaction
Query query = em.createQuery("DELETE USER u WHERE u.status = :status ");
query.setParameter("status", 'GOLD');
int results = query.executeUpdate();
//end transaction
UPDATE 하는 방법 또한 동일하다. 고로 UPDATE 예제는 생략하도록 하겠다.
이제 하고자 하는 이야기를 하자. 위의 예제는 의도하여 삽입하였다. 무슨 이야기? 예제에서 트랜젝션의 시작과 끝을 알리는 주석에 주목해보자. 타 작업(task)이 포함되어 있지 않고, 하나의 트랜젝션으로 묶여 있다. 왜 그럴까? 누가 그랬을까?
만일, 위의 예제를 실행하고 나서 다른 작업을 시도한다면, 의도한 데이터 저장/수정, 삭제 작업은 이루어지지 않을 것이다. 왜?
JPA는 EntityManager가 엔티티Entity의 영속성(Persistance)를 관리하고 있다. 엔티티는 많은 관계들로 연결되어 있고, 이 관계들도 EntityManager가 관리하고 있다. Vender에서 사용하는 것처럼 JPA에서 Update, Delete문을 사용하게 된다면, EntityManager는 할일이 엄청나게 많아 질 것이다. 그럼 EntityManager를 관할하는 WAS도 우리에게 불만을 내뿜게 될게 뻔하지 않은가? 고로, JPA는 (bulk) Update, Delete를 실행했을 경우, EntityManager는 사용한 엔티티들을 Detached 상태로 되돌려 놓고, 트랜젝션이 종료되기를 기다리도록 하였다. 그러므로, 의도한 데이터작업은 실행할 수 없는 것이다.
요약하자면, bulk UPDATE, DELETE 를 사용했을 시엔 테잎 갈고 하자.
참조 : EJB3 In Action, Debu Panda, Reza Rahman, Derek Lane, Manning, 2007
자바에서 문자열을 사용할때 도움을 주는 연산자 들은 많다. 하지만 흔히 권하는 방법은 String과 StringBuffer 그리고 StringBuilder 클래스들이다. 사용할 땐 다음을 고려해주면 된다.
- String은 한번 선언하면 변하지 않기 때문에, 사용하려는 문자열이 변하지 않을때 사용하도록 한다.
- StringBuffer는 동기화방식으로 저장되기 때문에, 멀티 쓰레드(multi Thread) 환경하에서 문자열 변경시에 사용하도록 한다.
- StringBuilder는 비동기화방식으로 저장되기 때문에, 싱글 쓰레드(Single Thread) 환경하에서 문자열 변경시 사용하도록 한다.
자바 1.5에서 StringBuilder가 추가된 이유는 위에서 보이는 차이점과 같이 동기화 문제이다. 문자열 수정시 동기화 작업을 거치게 되면 큰 오버헤드를 거칠 수 밖에 없어 성능에 직접적으로 영향을 준다.
고로, 싱글쓰레드에서 동작하는 문자열들은 StringBuilder로 작업하는 것이 옳다.
1. 클로저
http://jibbering.com/faq/faq_notes/closures.html
http://jibbering.com/faq/faq_notes/closures.html
List의 contains 메소드를 사용할 일이 있어서 equals() 메소드에 대하여 찾다가 다음과 같은 나이스 사용 예제를 찾게 되었다. 책에다 있는 내용이니궁금한점은 책을 찾다보도록 하자.
public boolean equals(Object otherObject){
if (this == otherObject )
return true;
if (otherObject == null)
return false;
if (getClass() != otherObject.getClass())
return false;
CareCustomer careCustomer = (CareCustomer) otherObject;
return (careCustomerId == careCustomer.careCustomerId
&& customerId == careCustomer.customerId);
}
public boolean equals(Object otherObject){
if (this == otherObject )
return true;
if (otherObject == null)
return false;
if (getClass() != otherObject.getClass())
return false;
CareCustomer careCustomer = (CareCustomer) otherObject;
return (careCustomerId == careCustomer.careCustomerId
&& customerId == careCustomer.customerId);
}
Recent Comments
동치미 on WP의 부활: //드루지기 안녕하
드루지기 on WP의 부활: 워드프레스 좋지요.
동치미 on 느림의 미학: [민달이] 감사합니
민달이 on 느림의 미학: 저도 여유를 가지자
동치미 on 철학을가진개발자 Vs 그렇지않은개발자: [데꾸벅] 막걸리
동치미 on 근황!: //kimgisa
kimgisa on 근황!: Email 주소 안
데꾸벅 on 철학을가진개발자 Vs 그렇지않은개발자: 장신정신 = 철학
동치미 on 근황!: 민달이님 때문이라도