Overloading(오버로딩)
같은 이름의 메서드를 여러 개 가지며 매개변수의 유형과 개수가 달라도 되는 기술
- 두 메서드가 같은 이름을 가지고 있으나 인자의 수나 자료 타입이 다른 경우를 뜻함(리턴 값만 다르게 갖는 오버로드는 작성할 수 없음)
오버로딩 예시
public double computeArea(Circle c) { ... }
public double computeArea(Circle c1, Circle c2) { ... }
public double computeArea(Square c) { ... }
Overriding(오버라이딩)
상위 클래스의 동작을 상속받은 하위 클래스에서 변경하기 위해 사용
- 상위 클래스의 메서드와 이름, signature가 같은 함수를 하위 클래스에 재정의하는 것(상속 관계에 있는 클래스 간에 같은 이름의 메서드를 정의하는 것)
오버라이딩 예시
public abstract class Shape {
public void printMe() { System.out.println("Shape"); }
public abstract double computeArea();
}
public class Circle extends Shape {
private double rad = 5;
@Override // 개발자의 실수를 방지하기 위해 @Override(annotation) 쓰는 것을 권장
public void printMe() { System.out.println("Circle"); }
public double computeArea() { return rad * rad * 3.15; }
}
public class Ambiguous extends Shape {
private double area = 10;
public double computeArea() { return area; }
}
public class Main {
public static void main(String[] args) {
Shape[] shapes = new Shape[2];
Circle circle = new Circle();
Ambiguous ambiguous = new Ambiguous();
shapes[0] = circle;
shapes[1] = ambiguous;
for(Shape s : shapes) {
s.printMe();
System.out.println(s.computeArea());
}
}
}
- Circle에서 printMe() 메서드를 재정의한다(오버라이딩을 할 때 개발자의 실수를 방지하기 위해 메서드 위에 @Override를 관례적으로 적는다)
기술 면접 질문 / 답안
Override 와 Overload를 설명해주실 수 있을까요?
오버라이드(Override)는 상속받은 메서드를 하위 클래스에서 재정의하는 과정입니다.
이는 상위 클래스의 메서드와 동일한 시그니처(메서드 이름, 파라미터 타입 및 개수)를 가지지만, 메서드 내부의 로직이나 행위를 변경할 수 있습니다.
오버라이딩은 다형성을 지원하는 중요한 메커니즘입니다.
오버로드(Overload)는 동일한 이름을 가진 메서드를 여러 개 정의하지만, 각각 다른 파라미터의 타입이나 개수를 가질 수 있습니다.
이를 통해 하나의 메서드 이름으로 다양한 유형의 입력을 처리할 수 있으며, 이는 메서드 사용의 유연성을 증가시킵니다.
오버로딩은 메서드의 리턴 타입으로 결정되지 않으며, 파라미터의 차이에 의해 결정됩니다.
JPA(Java Persistence API)
JPA는 자바에서 ORM(Object-Relational Mapping) 기술 표준으로 사용되는 인터페이스 모음, 실제적으로 구현된 것이 아니라 구현된 클래스와 매핑을 해주기 위해 사용되는 프레임 워크, JPA를 구현한 대표적인 오픈소스로는 Hibernate가 있음
ORM(Object-Relational Mapping)
애플리케이션 class와 RDB(Relational DataBase)의 테이블을 매핑(연결)하는 것(애플리케이션의 객체를 RDB 테이블에 자동으로 영속화 해주는 것)
장점
- SQL문이 아닌 Method를 통해 DB를 조작할 수 있어, 개발자는 객체 모델을 이용하여 비즈니스 로직을 구성하는데만 집중할 수 있음(내부적으로는 쿼리를 생성하여 DB를 조작하지만 개발자가 이를 신경쓰지 않아도 됨)
- Query와 같이 필요한 선언문, 할당 등의 부수적인 코드가 줄어들어, 각종 객체에 대한 코드를 별도로 작성하여 코드의 가독성을 높임
- 객체지향적인 코드 작성이 가능하다, 오직 객체지향적 접근만 고려하면 되기 때문에 생산성 증가
- 매핑하는 정보가 class로 명시 되었기 때문에 ERD를 보는 의존도를 낮출 수 있고 유지보수 및 리팩토링에 유리
- 기존 방식에서 MySQL 데이터베이스를 사용하다가 PostgreSQL로 변환한다고 가정할 때 새로 쿼리를 만들어야 하는데 ORM을 사용하면 쿼리를 수정할 필요가 없음
단점
- 프로젝트의 규모가 크고 복잡하여 설계가 잘못된 경우, 속도 저하 및 일관성을 무너뜨리는 문제점이 생길 수 있음
- 복잡하고 무거운 Query는 속도를 위해 별도의 튜닝이 필요하기 때문에 결국 SQL문을 써야할 수도 있음
- 학습비용이 비쌈
JPA(Java Persistance API)
- Java 진영에서 ORM(Object-Relational Mapping) 기술 표준으로 사용하는 인터페이스 모음
- 자바 어플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스
- 인터페이스 이기 때문에 Hibernate, OpenJPA 등이 JPA를 구현함
JPA 사용 이유
JPA는 반복적인 CRUD SQL을 처리해준다. JPA는 매핑된 관계를 이용해서 SQL을 생성하고 실행하는데, 개발자는 어떤 SQL이 실행될지 생각만하면 되고, 예측도 쉽게 할 수 있다.
추가적으로 JPA는 네이티브 SQL이란 기능을 제공해주는데 관계 매핑이 어렵거나 성능에 대한 이슈가 우려되는 경우 SQL을 직접 작성하여 사용할 수 있다.
JPA를 사용하여 얻을 수 있는 가장 큰 것은 SQL아닌 객체 중심으로 개발할 수 있다는 것이다. 이에 따라 당연히 생산성이 좋아지고 유지보수도 수월하다. 또한 JPA는 패러다임의 불일치도해결하였다.
예를 들면 JAVA에서는 부모클래스와 자식클래스의 관계 즉, 상속관계가 존재하는데 데이터베이스에서는 이러한 객체의 상속관계를 지원하지 않는다(상속 기능을 지원하는 DB도 있지만 객체 상속과는 다름).
이런 상속관계를 JPA는 아래와 같은 방식으로 해결하였다.
상속관계에 대한 접근도 제공해주는데 객체지향에는 연관관계라는 것도 있다. 코드로 따지면 Class에서 또 다른 Class Type을 필드 변수로 가지고 있는것임
JPA 저장 및 조회
저장
조회
JPA는 수정 메소드를 제공하지 않는다. 하지만 당연히 수정은 필요하기 때문에 JPA는 데이터 수정시, 매핑된 객체(테이블 데이터)를 조회해서 값을 변경 후 커밋하면 DB 서버에 UPDATE 문을 전송하여 UPDATE를 실행한다.
스프링에서 흔히 사용하는 것으로 알고있는 JPA는, JPA를 이용하는 spring-data-jpa 프레임워크이지 JPA는 아니다.
기술 면접 질문 / 답안
JPA는 언제 필요하고 언제 필요하지 않은지 설명해주실 수 있을까요?
JPA는 주로 복잡한 관계형 데이터 모델을 가진 애플리케이션 개발에 사용됩니다. 이를 통해 개발자는 데이터베이스 작업 을 객체 지향적으로 처리할 수 있으며, CRUD 작업을 간소화할 수 있습니다. 또한, 다양한 데이터베이스 제품과의 호환성을 제공하여 데이터베이스 독립성을 보장하고, 내장된 캐싱, 페이징, 트랜잭션 관리 기능을 통해 개발 및 유지보수 효율을 높일 수 있습니다.
그러나, 프로젝트가 단순한 데이터 모델을 가지고 있거나 높은 성능을 요구하는 경우, JPA는 필요하지 않을 수 있습니다. 이런 상황에서는 JPA의 오버헤드가 부담이 될 수 있으며, 직접 SQL을 사용하거나 더 경량화된 데이터 액세스 기술을 고려하 는 것이 나을 수 있습니다. 또한, NoSQL 데이터베이스를 사용하는 경우 JPA는 적합하지 않으며, 해당 데이터베이스 유형에 맞는 기술을 선택해야 합니다.
요약하자면, JPA는 복잡한 데이터 관계와 효율적인 개발이 중요한 경우 유용하지만, 프로젝트의 구체적인 요구사항과 기술적 맥락을 고려하여 적합한 데이터 액세스 방식을 결정해야 합니다.
JPA 더티 체킹
JPA(Java Persistence API)에서의 더티 체킹(Dirty Checking)은 엔티티 객체의 상태 변경을 자동으로 감지하고 데이터베이스와 동기화하는 메커니즘을 말합니다. 이 과정은 주로 트랜잭션이 끝날 때 발생하는데, JPA는 엔티티의 현재 상태와 처음 로딩했을 때의 상태를 비교하여 변경점이 있는지를 판단합니다.
더티 체킹의 작동 방식
- 엔티티 로딩 : JPA는 데이터베이스에서 엔티티를 로딩할 때, 해당 엔티티의 초기 상태를 스냅샷으로 저장합니다.
- 상태 변경 감지 : 애플리케이션에서 엔티티의 속성을 변경하면, 이 변경 사항은 메모리상의 엔티티 객체에만 반영됩니다.
- 트랜잭션 종료 시 변경 감지 : 트랜잭션이 커밋되기 직전, JPA는 스냅샷과 현재 엔티티 객체의 상태를 비교하여 변경된 부분을 감지합니다.
- 더티 체킹에 의한 업데이트 : 변경이 감지된 엔티티에 대해서는 JPA가 자동으로 UPDATE SQL 명령을 생성하고 실행하여 데이터베이스의 상태를 최신으로 업데이트합니다.
더티 체킹의 장점
- 개발 편의성 : 개발자는 엔티티의 상태를 직접 업데이트하는 SQL 문을 작성할 필요가 없으며, 객체의 상태를 변경하기만 하면 됩니다. 이후의 동기화 과정은 JPA가 자동으로 처리합니다.
- 성능 최적화 : 더티 체킹은 필요한 경우에만 데이터베이스 업데이트를 실행하기 때문에, 불필요한 데이터베이스 작업을 최소화할 수 있습니다.
주의점
- 더티 체킹은 편리하고 강력한 기능이지만, 때로는 예상치 못한 업데이트가 발생할 수 있습니다. 따라서 엔티티의 생명주기와 상태 관리에 주의를 기울이고, 필요한 경우에만 상태 변경이 일어나도록 관리하는 것이 중요합니다.
기술 면접 질문 / 답안
JPA의 더티 체킹이란 무엇인가요?
더티 체킹은 JPA의 핵심 기능 중 하나로, 애플리케이션의 엔티티 객체가 변경된 후 트랜잭션이 종료될 때, 변경된 내용을 자동으로 데이터베이스에 반영하는 메커니즘입니다. JPA는 엔티티 매니저(entity manager)를 통해 엔티티 객체를 관리하며, 각 트랜잭션 시작 시 엔티티의 초기 상태를 스냅샷으로 저장합니다. 트랜잭션이 종료되기 전, 엔티티 매니저는 스냅샷과 현재 엔티티 객체의 상태를 비교하여 변화가 있는 경우, 해당 변화를 SQL 업데이트 문으로 변환하여 데이터베이스에 반영합니다.
더티 체킹 덕분에 개발자는 엔티티 객체의 상태를 명시적으로 업데이트하지 않아도 되며, 이는 코드의 양을 줄이고, 버그 발생 가능성을 낮추는 데 도움이 됩니다. 또한, 이 기능은 JPA의 트랜잭션 관리와 밀접하게 연관되어 있어, 애플리케이션의 데이터 일관성을 유지하는 데 중요한 역할을 합니다.
JVM 이란 무엇이고 왜 필요한지 설명해주실 수 있을까요?
JVM은 자바 애플리케이션의 실행을 위한 핵심 컴포넌트로, 자바의 '한 번 작성하면 어디서나 실행(WORA, Write Once, Run Anywhere)'라는 철학을 실현합니다. 바이트코드 형태로 컴파일된 자바 애플리케이션은 JVM을 통해 다양한 운영 체제에서 실행될 수 있습니다. 이는 JVM이 운영 체제와 자바 애플리케이션 사이의 중개자 역할을 하기 때문입니다.
JVM의 중요한 기능 중 하나는 가비지 컬렉션(Garbage Collection)입니다. 이 기능은 더 이상 사용되지 않는 메모리 자원을 자동으로 회수하여 메모리 관리를 단순화합니다. 또한, JVM은 메모리 관리, 멀티스레딩 지원, 보안 관리 등과 같은 다양한 기능을 제공하여 애플리케이션의 안정적인 실행을 돕습니다.
결론적으로, JVM은 자바 애플리케이션의 플랫폼 독립성을 보장하고, 개발자가 메모리 관리와 같은 복잡한 시스템 수준의 작업에 대해 걱정하지 않도록 하여, 애플리케이션의 효율적인 개발과 안정적인 운영을 지원합니다.
'항해 99 > Spring' 카테고리의 다른 글
Spring Context (0) | 2024.04.10 |
---|---|
Spring AOP (0) | 2024.04.09 |
Call by Reference (0) | 2024.04.04 |
WebSocket 활용 웹 게임 구현 (0) | 2024.04.03 |
WebSocket - 실제 코드 분석 (1) | 2024.04.03 |