Week 12

Week 12
: 복습, 객체 지향, 디자인 패턴 등

✍️ 이제 멘토링 중반을 향해 달려가고 있다. 지난 날들을 되돌아 보았을 때, 나는 지나온 시간만큼 성장 했을까? 요즘 다시 되묻는 시간이 많아지는 것 같다. 그리고 공부를 하면 할 수록, 내가 공부한 내용을 다시 상기하며 입 밖으로 꺼낼 때 마다 자신감이 떨어지는 것을 느낀다. (더닝 크루거 효과인가?)

이 무기력을 이겨내려고 매일 다짐하지만 쉽게 이겨내지 못하는 내 자신이 한심하다고 생각하지만~ 부정적인 생각은 하지 않기로 오래 전 부터 약속 했으니까 핑크빛 미래를 생각하며 오늘 나눈 이야기들을 정리해봐야겠다!

나는 절망의 계곡에서 헤엄치는 중이다.

---

1. Statement, SQL Injection

지난 주차에서 해당 주제에 대해서 간단히 정리했지만, SQL Injection 에 대한 내용이 과제로 추가되어서 다시 한 번 살펴보는 시간을 가졌다.

Statement 란 무엇일까? 요청에 필요에 의해 작성된 쿼리를 분석하고 이를 컴파일하고, 커넥션을 통해 컴파일 된 쿼리를 데이터 베이스에 요청한 뒤 응답을 받아주는 객체를 의미한다. (즉, Statement 인터페이스는 Connection 객체를 통한 데이터 베이스 연결의 집합을 의미한다.)
이러한 Statement 는 문자열로 이루어진 쿼리를 분석하고 컴파일 하는데, 예를 들어 로그인을 한다고 가정한다면 사용자는 아이디와 비밀번호를 URL 쿼리 파라미터나 HTTP Body 에 입력값을 담아 요청 할 것이다.
이 때, 전송된 아이디와 비밀번호는 문자열로 이루어진 쿼리에 보통 + 연산(컴파일 시, StringBuilder 가 + 연산 수행!)을 수행하는데, Statement 객체는 이렇게 작성된 문자열을 1) 쿼리가 맞는지 분석하고 2) 적절한 쿼리라면 컴파일 하는 과정을 거친다.
여기서 문제가 발생한다.

만약 비밀번호를 입력 할 때, 쿼리문을 작성해서 요청을 보내면 어떻게 될까?
서버 사이드에서 작성된 쿼리 문자열에 사용자가 입력한 쿼리가 하나의 문자열로 합쳐지게 되고, Statement 객체가 해당 문자열을 컴파일하게 되고, 이를 서버가 데이터베이스에게 요청을 하게 된다면 서버는 의도하지 않는 응답을 받게 되는 보안 상 크리티컬한 이슈가 발생한다. 이를 SQL Injection 이라고 하는데, 외부에서 임의의 쿼리를 서버로 요청하므로써 컴퓨터 자원을 마비 시키거나 과도한 쿼리 요청으로 메모리 낭비를 유발 할 수 있다.

때문에 꼭 필요하지 않는 이상 PreparedStatement 객체를 이용해서 사용자의 입력을 받는 것이 좋겠다.

 

2. 객체 지향 4대 특성

객체 지향은 상속, 다형성, 캡슐화, 추상화의 특징을 가지는데, 나는 이들 특성이 어느 하나라도 빠지면 나머지 특성들이 존재할 이유가 없다고 생각된다. 그 만큼 각 특성은 끈끈한 연관관계를 가지고 있다. 이번에는 따로 멘토님께서 깊게 질문해주시진 않았지만 나름대로 정리한 내용을 작성해보자 한다.

📍 상속 (확장과 구현)
: Java 를 공부하면 할 수록 상속이라는 번역은 객체 지향과는 조금 다른 개념이 아닐까 하고 생각한다.
상속이라 함은 부모의 특징이나 유전자, 재산 등을 물려 받는다는 의미로 위에서 아래로 되물림되는 개념인 것에 반해, 객체 지향에서의 상속은 부모의 특징을 그대로 내려 받으면서 원한다면 자식이 부모가 될 수 있다. (Wrapper)
위에서 언급한 상속의 개념에서 부모와 자식 간의 관계를 봤을 때, 나는 우리 아버지가 될 수 있을까? 물론 자식은 부모의 거울이라는 말이 있기는 하지만 본질적으로 나는 나고 부모는 부모다. 그래서 내가 아무리 우리 아버지랑 똑같이 생기고 행동한다고 해도 누구든지 나라는 것을 알 수 있을 것이다.

객체 지향에서의 상속은 다르다. 하위 클래스는 상위 클래스로 감싸질 수 있기 때문에 잘 모르는 사람이 와서 들여다 보면 상위 클래스로 인식된다. 이러한 객체 지향의 상속 개념을 현실로 가져와서 대입 해본다면 논리에 어긋난다. 왜 그럴까?
그것은 상속을 바라보는 관점이 다르기 때문인데, 현실에서의 상속은 관계도를 나타내고, 객체 지향에서의 상속은 분류도를 나타내기 때문이다. 처음 클래스와 객체의 차이에 대해서 공부 할 때를 생각해보자. 클래스는 객체들을 정의한 스펙이라고 볼 수 있다.
즉, 여러 카테고리 중 하나 인 것이다. (클래스를 사전에서 찾아보면 분류라고 나오기도 한다.)

관계도에서의 나를 아버지라고 한다면 논리에 어긋나지만, 분류도에서 사람을 동물이라고 하는 것은 논리에 어긋나지 않는다.
즉, 객체 지향의 상속은 이러한 분류도를 기준으로 해당 클래스가 어떤 상위 카테고리(클래스)를 확장(extends)하는지, 구현(implments) 하는지를 의미한다. 때문에 많은 영상이나 글에서 언급되지만 데이터 베이스나 프로그램 설계 단계에서 관점을 객체에 두지 말라고 하는 것이 결국 객체에 관점을 둔다면 자연스럽게 분류도가 아닌 관계도를 기반으로 설계를 할 가능성이 생길 수 있으며, 이는 객체 지향의 특성과 원칙에 어긋나는 것이기도 하지만 그 만큼 유지보수도 어려워지기 때문이다.

📍 다형성
: 앞에서 설명한 상속에서 하위 클래스의 구현체는 상위 클래스로 인식 될 수 있다고 했다. 이렇게 객체가 다른 여러가지 타입으로 변경 되어도 하나의 객체가 여러가지 타입을 가질 수 있는 특징을 다형성이라고 한다. 이러한 다형성은 Java 에서 객체에만 국한되는 것이 아니다.
상속 개념에 의해서 상위 클래스를 확장하거나 구현하고 있는 클래스가 하나 있다고 가정하자. 해당 클래스는 상위 클래스에서 정의하거나 명세한 메소드, 멤버 필드들을 재정의 하거나 새롭게 구현 할 수 있다.
이렇게 이미 정의된 메소드, 멤버 필드들을 재정의하거나 새롭게 구현하는 것 또한 다형성의 특징을 가지는데, 상위 클래스에서 정의한 내용들이 상속에 의해 다른 내용으로 교체 될 수 있기 때문이다. 이를 오버라이딩이라고 한다.
오버로딩이라는 것은 무엇일까? 클래스 내부에 같은 이름을 가진 명세가 다른 메소드들을 여러가지 만들 수 있다. 이 또한 같은 이름을 가진 메소드가 다른 형식으로 존재하기 때문에 하나의 메소드가 다른 명세의 메소드로 교체될 수 있기 때문에 다형성의 특징을 가진다.

이처럼 다형성은 하나의 객체가 다양한 타입으로 정의 될 수 있기 때문에 타입을 유연하게 정의 할 수 있다는 장점을 가진다.(확장성)

📍 캡슐화
: 상속과 다형성의 특징을 가지고 설계하게 된다면 결국 분류도 개념에 의해서 계층적인 구조를 가지게 되는데, 이러한 계층 구조는 하위 클래스에 접근하기 위해 상위 클래스를 알고 있어야 한다는 전제가 필요하다. 이 말은 참조 변수의 타입은 상위 클래스이면서 구현체는 하위 클래스로 이루어져 있을 때를 의미하는데, 참조 변수의 타입이 구현체 클래스로 정의되어 있다면 관계 없다.
하지만 다형성에서 얻을 수 있는 확장성의 장점을 적극 활용하기 위해서 결국 참조 변수의 타입을 상위 클래스로 정의하는 경우가 많은데, 이렇게 상위 클래스로 정의된 참조 변수는 하위 클래스가 실질적인 구현체임에도 불구하고 하위 클래스에서만 정의된 필드나 메소드는 접근하지 못한다.

이처럼 하위 클래스 구현체를 상위 클래스 타입으로 감싸고 있는 형태를 캡슐화라고 하는데, 캡슐화는 다형성, 상속과 맞물려서 자연스럽게 하위 클래스 내부를 은닉하고 쉽게 접근 할 수 없도록 하는 특징을 가진다. 때문에 하위 클래스로 구현된 상위 클래스 타입을 가지는 참조 변수에서 하위 클래스의 지역적인 필드나 메소드에 접근하기 위해서는 캐스팅을 하는 과정이 필요하다. 이에 Java 는 instanceof 키워드를 통해 해당 참조 변수가 특정 클래스의 타입과 맞는지 확인하고, 이를 하위 클래스에 맞게 캐스팅하여 지역적 필드와 메소드를 사용 할 수 있다.

📍 추상화
: 여러 클래스들이 가지는 공통적인 특성과 요소들을 하나의 인터페이스 혹은 추상 클래스에 명세하고, 이러한 인터페이스, 추상 클래스에 명세된 특성과 요소가 필요한 클래스들이 이를 확장, 구현하도록 하는 것을 추상화라고 한다. 즉, 공통 분모는 분명한데 각 분류(클래스) 별로 공통 분모까지 도출하는 과정이 다를 때 이러한 추상화를 통해서 각각의 클래스들은 자신의 방식으로 특성과 요소들을 정의할 수 있게 된다.

추상화를 적극 활용한다면, 캡슐화나 다형성의 특징과 맞물려서 하위 클래스로 구현된 상위 클래스의 타입을 가지는 참조 변수(캡슐화)는 구현체가 변경되어도(다형성) 언제나 같은 메소드를 호출 할 수 있게 된다.

 

3. 객체 지향 5대 원칙

객체 지향 5대 원칙? 위에서 정리한 객체 지향 4대 특징과 비슷한 것 같은데 뭐가 다른걸까?
객체 지향의 4대 특징은 객체 지향 프로그래밍을 지탱하고 있는 근본이나 뿌리의 의미를 가진다. 그렇기 때문에 객체 지향의 4대 특징은 객체 지향 프로그래밍에서 없으면 안되는 존재들이다. 하지만 객체 지향 5대 원칙은 객체 지향적으로 프로그래밍 했을 때 해당 원칙을 따른다면 생산성과 유지보수성 그리고 개발의 확장성, 협업 등 많은 부분에서 유리하기 때문에 권고 사항이라고 생각하면 좋을 것 같다.
즉, 4대 특징 중 하나라도 빠진다면 객체 지향 프로그램이라고 할 수 없지만 5대 원칙을 모두 따르지 않더라도 문제가 이렇게 짜여진 프로그램이 객체 지향 프로그램이 아니라고 할 수 없다. (팀의 성향에 따라 코드 스타일이 달라지는 것 처럼 개발 스타일의 원칙을 정의했다고 생각하면 좋을 것 같다.)

이러한 5대 특징은 SOLID 라는 명칭을 가지는데
- SRP (Single Responsibility Principle) : 단일 책임 원칙
- OCP (Open Close Principle) : 개방 폐쇄 원칙
- LSP (Liskov Substitution Principle) : 리스코프 치환 원칙
- ISP (Interface Segregation Principle) : 인터페이스 분리 원칙
- DIP (Dependency Inversion Principle) : 의존성 역전 원칙
의 원칙의 앞 글자를 따서 만들어졌다.

이러한 원칙들은 어떤 것을 의미할까?

📍 단일 책임 원칙 - SRP
: 문장 그대로 하나의 클래스는 하나의 책임만을 가지도록 설계하는 원칙을 뜻한다. 이전에 공부했던 동적 페이지를 응답하기 위해 하나의 JSP 이나 서블릿에서 DB 커넥션 설정이나 조회된 데이터를 바탕으로 비즈니스 로직을 수행하고, 동시에 해당 데이터를 가공하여 화면으로 만들어 클라이언트에서 응답하는 과정을 거친다.
이는 하나의 클래스에서 여러 역할을 맡게 되는 경우인데, 이러한 경우에 여러 역할을 맡은 클래는 책임의 무게가 무거워지게 된다. (결합도가 높고, 응집도는 낮아진다.) 이런 경우, 해당 클래스를 의존하는 클래스들이 많아지게 되고, 관심사의 분리가 이루어지지 않기 때문에 유지보수나 확장에서 유연하지 못하다.
때문에 이러한 문제점을 해결하기 위해서 하나의 클래스는 하나의 역할만을 가지도록 하는 원칙이 단일 책임 원칙이다.

📍 개방 폐쇄 원칙 - OCP
: 자신의 확장에는 열려 있으나 변경에는 닫혀 있도록 설계하는 원칙을 뜻한다.
여기서 확장은 쉽게 이해가 되는데, 변경에 닫혀있다는 것은 어떤 것을 의미하는걸까?
단일 책임 원칙을 따르다보면 결국 각각의 클래스는 최소한의 역할만을 가지게 되고, 슈퍼 클래스(혹은 인터페이스)를 통해서 각자의 역할을 잘 조합해 도출된 결과를 슈퍼 클래스가 클라이언트에게 응답 할 것 이다.
이 때, 클라이언트에서 기존 요청에 대한 요구사항이 변경 되었다고 가정 했을 때, 슈퍼 클래스에서 변경된 부분을 응답하도록 수정한다면 슈퍼 클래스만 변경되는 것이 아닌 해당 클래스 내부에 있는 각각의 역할들까지도 변경에 대한 영향을 미치게 된다. 이 것이 바로 자신의 변경에 대해 닫혀 있다는 의미를 가진다.
즉, 개방 폐쇄 원칙은 슈퍼클래스의 하위 클래스 확장에는 열려 있고, 자신의 내부가 변경되거나 교체되는 것에는 닫혀 있게 되면서 컴파일 타임에서 생길 수 있는 의존성을 인터페이스에게 역전시켜 런타임의 의존성을 위임하여 재사용성이나 확장성 유연성을 위한 원칙이다.

📍 리스코프 치환 원칙 - LSP
: <자바의 신> 책을 읽으며 공부하면서 Inheritance (상속)과 Composition (합성, 조합)에 대해 공부하면서 함께 공부했던 내용이다. 그 때 공부했던 내용을 떠올려보자. 리스코프 치환 원칙이란 다형성의 특징을 바탕으로 이야기하고 있다. 즉, 하나의 구현체는 다른 타입으로 교체 될 수 있어야 한다는 원칙인데, <스프링 입문을 위한 객체 지향의 원칙> 이라는 책에서는
- 하위 클래스 is a kind of 상위 클래스
- 구현체 클래스 is able to 인터페이스
라는 문장이 리스코프 치환 원칙에 적합한 예시라고 말하고 있는데, 이 부분에 동의한다. 왜냐하면 앞에서 4대 특징에 대해 이야기 할 때도, 단순히 is a 관계에서는 다형성의 특징에 어긋나는 경우가 발생 할 수 있다. 하지만 is a kind of 라는 관점으로 클래스를 바라보게 되면 자연스레 분류로 정의되고, 이러한 분류는 자신의 상위 분류로 대처 될 수 있다.

여러 쇼핑몰의 카테고리를 한번 살펴보자.
대분류에 전자제품이 있고, 중분류에 가전제품, 모바일기기 등으로 나뉘어져 있으며, 이 중에 모바일기기 중분류의 소분류에는 휴대전화, 태플릿 PC, 스마트 워치 등이 존재하고 있다고 가정해보자.
여기서 짚고 넘어가야 할 점은 하위의 소분류들은 최상위에 위치한 대분류로도 불릴 수 있다. 즉, 스마트 워치는 모바일기기의 한 종류이기도 하면서 전제제품의 종류이기도 하기 때문이다. 이렇게 하위의 클래스(분류)가 상위의 클래스로 대처되어도 객체의 동작에 있어 문제가 없도록 하는 원칙이 리스코프 치환 원칙이다.

반면 이렇게 분류도의 관점이 아닌 관계도의 관점으로 바라 봤을 때를 살펴보자.
4대 특징의 다형성 파트에서 간략히 설명했던 내용인데, 최상위 클래스에 할아버지가 위치하고 그의 자식으로는 아버지, 아버지의 자식으로는 딸이 있다고 가정하자. 그렇다면 다형성의 특징에 의해서 아버지 큰딸 = new 딸() 이런 식으로 하위 클래스 구현체는 상위 클래스 타입으로 감싸질 수 있다. 하지만 이러한 구조에서 딸이 과연 아버지의 역할을 충분히 해낼 수 있을까? 혹은 우리는 큰 딸을 아버지라고 부를 수 있을까? 정답은 '아니오'이다.
이 처럼 리스코프 치환 원칙을 잘 따랐을 때, 해당 프로그램을 쉽게 이해 할 수 있게 된다.

📍 인터페이스 분리 원칙 - ISP
: 인터페이스로 분리한다. 결국 주체와 관점이 다를 뿐, 단일 책임 원칙처럼 하나의 클래스의 역할을 분리분산 해주고자 하는 것에 의미를 가진다. 단일 책임 원칙과 다른 점은 인터페이스를 통해 각 역할을 분리하고, 필요한 역할을 클래스에서 구현하여 사용하도록 하는 원칙이다. 하지만 인터페이스 분리 원칙은 객체 지향 논리에서 조금 어긋나는 부분이 존재하는데, 하나의 클래스에서 필요로 하는 인터페이스들을 구현한다고 가정 했을 때, 해당 클래스의 객체들은 각자의 위치에서 자신이 구현하고 있는 모든 인터페이스를 사용 할 수 있게 된다. 

즉, 여러 개의 인터페이스를 구현하고 있는 클래스는 인터페이스에 의해서 여러 가지 역할을 가지게 되는데, 결국 이러한 클래스가 인스턴스화 되면 역할에 맞는 메소드를 제외한 현재 역할에서는 쓸모 없는 메소드를 호출 할 수 있는 상황이 발생 할 수 있기 때문에 권장하는 원칙은 아니라고 한다.

📍 의존성 역전 원칙 - DIP
: 고수준의 모듈이 저수준 모듈의 구현체에 의존해서는 안된며 저수준 모듈의 구현체가 추상화된 고수준 모듈에 의존해야 한다는 원칙이다. 여기서 고수준 모듈이란 어떠한 의미를 가진 인터페이스를 의미하며, 이러한 인터페이스의 실질적인 구현체를 저수준 모듈이라고 하는데 , 만약 구현체에 직접적으로 의존하게 된다면 추후에 다른 구현체로 변경하기 위해서는 의존하고 있는 객체의 코드들은 변경되는 구현체(저수준 모듈)에 영향을 받을 수 밖에 없다. 이렇게 된다면 유지보수나 유연성 등 많은 부분에서 효과적이지 못하기 때문에 추상화한 인터페이스를 통해 실질적 구현체들의 의존성을 주입 받는다면 인터페이스와 의존 관계를 가진 객체는 인터페이스의 구현체에 영향을 받지 않아 별도의 수정을 거칠 필요 없이 인터페이스의 구현체만 바꿔주면 된다.

---

💥 동적 언어, 정적 언어, 덕 타이프

💥 Stack Frame, Java Capturing

💥 Message Queue