Java 개발자라면 누구나 한번쯤 getter와 setter 메서드를 작성해 보았을 것입니다. 하지만 정작 왜 이러한 패턴을 사용하는지 깊이 생각해 본 적이 있으신가요? 이 글에서는 객체지향 프로그래밍의 핵심 원칙인 캡슐화와 함께 getter/setter의 필요성과 장점을 알아보겠습니다. 객체지향 설계 // 잘못된 방식 ( 외부에서 직접 접근 가능 ) public class Person { public String name ; } // 올바른 방식 ( 외부에서 getter 와 setter 를 통해서만 접근 가능 ) public class Person { private String name ; // private 로 선언하여 외부 접근 차단 public String getName () { return name ; } public void setName (String name) { this . name = name; } } 캡슐화(Encapsulation) 객체지향의 4가지 특징 중 하나인 캡슐화는 데이터(속성)와 그 데이터를 다루는 코드(기능)를 하나로 묶고, 외부에서 데이터를 함부로 바꾸지 못하게 보호하는 것입니다. 위 예제에서 보면 name이라는 변수가 데이터라고 볼 수 있습니다. getName과 setName은 데이터를 다루는 코드라고 볼 수 있습니다. 데이터와 데이터를 다루는 코드가 하나로 묶여 있습니다. 변수의 접근제어자를 private으로 선언했기 때문에 외부에서 데이터를 함부로 바꿀 수 없습니다. 변수의 접근제어자를 private으로 바꾸고, getter/setter를 만드는 이 일반적인 방법은 이 캡슐화를 하기 위함입니다. 단일 책임 원칙 (SRP) getter와 setter는 데이터 접근 및 수정 책임을 클래스 내부에 집중시켜, 외부 코드가 데이터 조작 로직을 알 필요 없게 합니다. 외부에서 직접 변수에 접근하면, 데이터 검증 로직을 추가할 때마다 모든 호출 코드를 수...

Java의 예외(Exception)은 크게 두 가지로 나루 수 있습니다. 바로 Checked Exception 과 Unchecked Exception 입니다. 예외 처리나 트랜잭션 처리 같은 기능을 구현할 때 꼭 알아야 하는 중요한 개념이지만 기초 공부를 충분히 하지 않았다면 정확히 이해하지 못하고 넘어가기 쉬운 부분입니다. 최대한 쉽게 설명해보겠습니다. Exception의 상속 구조 Object └── Throwable ├── Error (Unchecked) └── Exception (Checked and Unchecked) ├── RuntimeException (Unchecked) └── Other Exceptions (Checked) 모든 예외의 최상위 클래스는 Throwable이고, Throwable을 상속하는 Exception은 Checked와 Unchecked를 모두 포함합니다. Checked Exception 중 하나인 SQLException을 보면 Exception을 상속 받고 있는 걸 알 수 있습니다. public class SQLException extends java.lang.Exception implements Iterable<Throwable> Unchecked Exception 중 하나인 NullPointerException을 보면 RuntimeException을 상속 받고 있는 걸 알 수 있습니다. public class NullPointerException extends RuntimeException 💡 IntelliJ에서 Ctrl + Shift + N으로 예외 클래스 이름을 검색해보면 해당 예외가 어떤 클래스를 상속받는지 직접 확인할 수 있습니다. Checked Exception이란? Checked Exception은 컴파일 시점에 반드시 예외 처리를 해야 하는 예외 입니다. 예외 처리를 하...

Java 개발을 하다 보면  기본형(primitive type)과 참조형(reference type)의 차이가 정확히 뭔지 헷갈릴 때가 있습니다. Java 개발자라면 정확하게 알고 있어야 하는 내용인 것 같아서 간단하게 정리해보았습니다. Java Wrapper 클래스란? Wrapper 클래스 는 Java의 기본형 타입을 객체로 다룰 수 있게 해주는 클래스입니다. 아래와 같이 총 8개가 있습니다. 기본형(Primitive Type) Wrapper 클래스(Reference Type) byte Byte short Short int Integer long Long float Float double Double char Character boolean Boolean Wrapper 클래스가 필요한 경우 null 처리가 필요할 경우 기본형(Primitive Type)은 null을 가질 수 없습니다. null일수 있는 경우라면 Wrapper 클래스를 써야 합니다. 컬렉션 사용 시 필요 List, Set, Map같은 컬렉션 클래스는 객체만 저장할 수 있습니다.  기본형(Primitive Type)을 바로 저장하려고 하면 에러가 발생합니다. Wrapper 클래스에서 제공하는 메소드 사용 시 필요 각 Wrapper 클래스에는 형변환을 쉽게 할 수 있게 도와주는 메소드나 해당 자료형의 MIN, MAX값이 정의된 상수 등을 제공합니다. 제네릭(Generic) 사용 시 필요 class Box< T > { T value ; } Box<Integer> box = new Box<>(); 제네릭(Generic)은  기본형(Primitive Type)을 지원하지 않습니다. 오토박싱(Auto-boxing)과 언박싱(Unboxing) Integer wrapped = 10 ; // 오토박싱 : int 10 이 Integer 로 변환 int primitive = wrapped ; // 언박싱 : Integer 가 int 로 변환 ...

Java에서 String 객체는 불변(immutable)입니다. 한번 생성된 문자열은 변경할 수 없으며, 이러한 특성 때문에 문자열 연산을 할 때 다양한 방식이 존재합니다. 매번 '+' 연산자만을 이용해서 문자열을 합친다면 큰 문제가 발생할 수도 있습니다.  Java 공식 문서의 Class String 부분을 보면 제일 윗 부분에 "모든 문자열은 String 클래스의 인스턴스로 구현되어 있고, 상수이며, 생성된 후에는 값을 변경할 수 없다"라고 명시되어 있습니다. https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/String.html '+' 연산자를 이용한 문자열 연결 '+' 연산자는 가장 일반적인 문자열 연결 방법입니다. 적은 양의 문자열 연결에 적합합니다. 이 적은 양이 어느 정도 인지가 애매한데 이건 아래에서 성능 비교를 해보면서 다시 알아보겠습니다. JDK 1.5 이후의 컴파일러 최적화 JDK 1.5부터 Java 컴파일러는 String의 '+' 연산을 내부적으로 StringBuilder를 사용하여 최적화 합니다. // 내가 작성한 코드 String result = "Hello" + " " + "World" ; // 컴파일러가 변환하는 코드 (JDK 1.5 이상 ) String result = new StringBuilder().append( "Hello" ).append( " " ).append( "World" ).toString(); 한 줄 vs 여러 줄 String 연산의 차이 한 줄에서 여러 문자열을 연결할 때는 하나의 StringBuilder 객체만 생성되어 효율적으로 작동합니다. // 한 줄 연산 - 효율적 ( 하나의 StringBuilder 사용 ) String result = ...

INNER JOIN, LEFT OUTER JOIN 2개만 알면 거의 모든 요구 사항이 커버가 됩니다. 하지만 가끔 저 2개만 가지고는 안될 때가 있습니다. 실무에는 정말 다양한 요구 사항이 있기 때문에 모든 JOIN 유형을 다 알아두면 분명 도움이 될 일이 있을 겁니다. 샘플 테이블 및 데이터 생성 스크립트와 SQL은 PostgreSQL 기준으로 작성되었지만 대부분의 DB에서 그대로 사용이 가능합니다. 샘플 테이블 및 데이터 생성 스크립트 CREATE TABLE departments ( department_id INT PRIMARY KEY , /* Oracle이면 INT 대신 NUMBER */ department_name VARCHAR ( 50 ) NOT NULL /* Oracle이면 VARCHAR 대신 VARCHAR2 */ ) ; CREATE TABLE employees ( employee_id INT PRIMARY KEY , /* Oracle이면 INT 대신 NUMBER */ employee_name VARCHAR ( 50 ) NOT NULL , /* Oracle이면 VARCHAR 대신 VARCHAR2 */ department_id INT , /* Oracle이면 INT 대신 NUMBER */ manager_id INT , /* Oracle이면 INT 대신 NUMBER */ FOREIGN KEY (department_id) REFERENCES departments(department_id) ) ; INSERT INTO departments (department_id, department_name) VALUES ( 10 , '개발팀' ) ; INSERT INTO departments (department_id, department_name) VALUES ( 20 , '마케팅팀' ) ; INSERT INTO departments (depa...

DB의 테이블명과 칼럼명을 정할 때 대문자로 할지 소문자로 할지는 상당히 고민되는 부분이다. 명확한 표준은 없지만 최근에는 거의 소문자로 통일되는 추세다. 그 이유를 알아보자. 대문자(UPPER CASE)를 피해야 하는 이유 대소문자 구분 문제 Windows에서는 대소문자를 구분하지 않는 것이 기본값이고, Linux에서는 대소문자를 구분하는 것이 기본값이다. 그리고 이 설정값은 변경이 가능하기도 하다. 이런 변수가 있기 때문에 소문자나 대문자로 통일하는 것이 좋다. PostgreSQL 같은 경우는 테이블 및 칼럼명을 무조건 소문자로 변환하여 저장한다. 꼭 대문자로 하려면 큰따옴표(")로 감싸야 하기 때문에 일반적으로 소문자 사용이 권장된다. 데이터 정렬 방식(collation)을 대소문자를 구분하도록 설정할 수 있는 DB도 있고, 일부 DBMS 관리 프로그램에서 대소문자 인식이 제대로 되지 않을 수도 있다. 여기까지만 봐도 소문자로 해야 하는 이유가 너무나 많다. 가독성 저하 SELECT id, name, created_date FROM users; 위 쿼리와 같이 이미 많은 개발자들이 SQL 예약어는 대문자 테이블명, 칼럼명은 소문자로 하는 것이 가독성이 더 좋다고 느끼고 있다. 여러 강의나 자료, 블로그 등을 봐도 대부분 이 방법을 선호하는 것 같다. ORM/프레임워크와의 통합 문제 대부분의 ORM/프레임워크는 소문자 + 언더스코어(_)를 칼럼명 규칙으로 채택하고 있다. 칼렴명이 대문자라면 문제가 발생할 수 있다. 대문자를 쓰는 경우 Oracle일 경우 Oracle은 PostgreSQL과는 반대로 기본적으로 테이블명과 칼럼명을 대문자로 변환하여 저장한다. 그래서 그런지 오래전부터 대문자로 하는 게 관례로 굳어져 왔다. 그렇다고 하더라도 Oracle의 가격이 비싸기 때문에 다른 DB로 변경하는 경우가 많으므로 소문자+언더스코어(_)로 하는 게 좋을 수 있다. 조직의 네이밍 규칙이 대문자일 경우 이미 잘 돌아가고 있거나 조직의 네이밍 규칙이 대문자일 ...

제가 일하다가 머리 식힐 때 자주 보는 개발자 커뮤니티 사이트를 소개해볼까 합니다. 혼자 공부만 하기 보다는 다른 개발자들과 고민, 경험, 관심사 등을 공유하는 것도 개발자로서 성장하는데 도움이 된다고 생각합니다. OKKY https://okky.kr 굉장히 오래된 전통 있는 사이트입니다. 사용자들의 활동도 활발하고, 영양가 있는 글들도 가끔 올라옵니다. 주로 SI/SM에 종사하는 개발자가 많고, 프리랜서 개발자도 많고, 취준생도 많습니다. 장점 ㆍ로그인을 하지 않아도 글을 볼 수 있다. ㆍQ&A게시판에 질문을 올리면 답변이 잘 달린다. ㆍ활동 점수라는 게 있어서 사용자들이 꾸준하고 활발하게 활동한다. ㆍJobs게시판에는 프리랜서 일자리가 보기 좋게 잘 정리되어 있고, 활발하게 올라온다.     * 대부분이 평균보다 낮은 단가를 제시한다는 의견이 많으니 이 부분은 잘 생각해서 구직을 해야 한다. 단점 ㆍ글이 올라오는 속도가 좀 느리다. ㆍ가끔 지나치게 진지한 사람들이 있다. 블라인드 IT 앤지니어 채널 앱으로만 접속 가능 네카라쿠배, 몰두센, 메웅교농베, 기타 대기업 회사 개발자들이 많습니다. 주로 서비스 업계에 종사하는 개발자가 많고, SI/SM을 무시하고, 조롱하는 분위기가 있어서 저같은 SI/SM 개발자들은 약간 거부감이 있을 수도 있습니다. 그렇다고 하더라도 유용한 정보가 꽤나 올라오는 곳입니다. 앤지니어 채널 외에도 회사 리뷰가 굉장히 많이 올라오기 때문에 구직 활동할 때는 꼭 봐야 할 곳입니다. 장점 ㆍ사용자가 재직중인 회사가 공개되기 때문에 다른 곳보다는 조금 더 신뢰할 수 있는 정보를 얻을 수 있다. ㆍ상위 레벨의 개발자가 많아서 그런지 가끔 수준 높은 글들이 보이기도 한다. ㆍ앱이기 때문에 내가 올린 글에 답변이 달리거나 내가 관심있는 글에 새로운 답변이 달리거나 하면 인지하기 쉽다. ㆍ반말이나 형이라고 부르는 문화가 있어서 딱딱하지 않은 분위기다. 단점 ㆍ약간 그들만의 세상이라는 느낌이 많이 드는 곳이다. 내가 부족하다...