객체지향 프로그래밍 특징
- 캡슐화(Encapsulation)
캡슐화는 객체의 상태(속성, 필드)와 행동(메서드)을 하나의 단위로 묶는 개념
객체의 내부 데이터는 외부에서 직접 접근할 수 없도록 보호되며, 필요한 경우 공개된 메서드를 통해서만 접근 가능하게 한다
-> 객체의 무결성을 유지하고, 데이터의 직접적인 변경을 방지할 수 있다
public class Car {
private String model; // private로 선언된 속성 (캡슐화)
private int speed;
// public 메서드를 통해서만 접근 가능
public void setModel(String model) {
this.model = model;
}
public String getModel() {
return model;
}
}
- 상속(Inheritance)
상속은 기존 클래스(부모 클래스, 슈퍼 클래스)의 속성과 메서드를 새로운 클래스(자식 클래스, 서브 클래스)가 물려받아 사용할 수 있게 하는 개념
-> 코드 재사용성을 높이고, 공통된 기능을 여러 클래스에서 쉽게 구현할 수 있게 한다.
public class Vehicle {
protected int speed;
public void move() {
System.out.println("The vehicle is moving.");
}
}
public class Car extends Vehicle {
private String model;
public void showModel() {
System.out.println("The model is " + model);
}
}
- 다형성(Polymorphism)
다형성은 동일한 인터페이스나 부모 클래스를 상속받은 객체들이 각기 다른 방식으로 행동 할 수 있는 능력이다. 메서드 오버라이딩과 메서드 오버로딩이 있다.
public class Animal {
public void makeSound() {
System.out.println("Some generic animal sound");
}
}
public class Dog extends Animal {
@Override
public void makeSound() {
System.out.println("Bark");
}
}
public class Cat extends Animal {
@Override
public void makeSound() {
System.out.println("Meow");
}
}
public class Main {
public static void main(String[] args) {
Animal myDog = new Dog();
Animal myCat = new Cat();
myDog.makeSound(); // Bark
myCat.makeSound(); // Meow
}
}
- 추상화(Abstraction)
추상화는 불필요한 세부사항을 숨기고 중요한 정보만 드러내는 것이다.
객체가 가진 속성과 메서드를 공통적인 인터페이스나 추상 클래스로 정의하고, 구현은 하위 클래스에서 책임진다.
public abstract class Shape {
// 추상 메서드 (구현은 하위 클래스에서 제공)
public abstract double getArea();
}
public class Circle extends Shape {
private double radius;
public Circle(double radius) {
this.radius = radius;
}
@Override
public double getArea() {
return Math.PI * radius * radius;
}
}
public class Main {
public static void main(String[] args) {
Shape circle = new Circle(5);
System.out.println("Area of circle: " + circle.getArea());
}
}
SOLID
SOLID는 객체지향 설계 원칙 중에서 가장 중요한 다섯 가지 원칙을 나타내는 약어이다. 이 원칙들은 유지보수성, 확장성, 가독성을 높이기 위해 설계된 원칙들로, 객체지향 프로그래밍에서 견고하고 유연한 소프트웨어를 개발하는 데 도움을 준다.
- 단일 책임 원칙(SRP: Single Responsibility Principle)
원칙: 하나의 클래스는 오직 하나의 책임만 가져야 한다.
-> 클래스는 하나의 기능만 수행하고, 그 기능에 대한 변경 사유는 하나뿐이어야 한다는 의미이다.
-> 책임이 많을수록 클래스를 변경해야 할 이유가 많아져, 유지보수가 어려워진다.
public class User {
private String name;
private String email;
// 사용자 정보 저장 관련 로직
public void saveUserToDatabase() {
// DB에 사용자 저장하는 로직
}
// 이메일 보내기 관련 로직 (단일 책임 원칙 위반)
public void sendEmail(String message) {
// 이메일 전송 로직
}
}
이 경우, 사용자 정보 저장과 이메일 전송이라는 두 가지 책임이 있어 단일 책임 원칙을 위반한다. 이를 분리한 코드가 아래의 코드이다.
public class User {
private String name;
private String email;
// 사용자 정보만 다루는 클래스
}
public class EmailService {
public void sendEmail(String email, String message) {
// 이메일 전송 로직
}
}
- 개방-폐쇄 원칙(OCP: Open/Closed Principle)
원칙: 클래스는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다
-> 기존 코드를 수정하지 않고 새로운 기능을 추가할 수 있도록 설계해야 한다
-> 변경으로 인한 리스크를 줄이고, 시스템의 유연성을 높일 수 있다.
// 잘못된 예시: 할인 정책 변경 시 기존 코드 수정 필요
public class DiscountService {
public double applyDiscount(double price, String discountType) {
if (discountType.equals("fixed")) {
return price - 10;
} else if (discountType.equals("rate")) {
return price * 0.9;
}
return price;
}
}
public interface DiscountPolicy {
double applyDiscount(double price);
}
public class FixedDiscountPolicy implements DiscountPolicy {
@Override
public double applyDiscount(double price) {
return price - 10;
}
}
public class RateDiscountPolicy implements DiscountPolicy {
@Override
public double applyDiscount(double price) {
return price * 0.9;
}
}
- 리스코프 치환 원칙(LSP: Liskov Substitution Principle)
원칙: 서브 클래스는 언제나 자신의 부모 클래스를 대체할 수 있어야 한다
-> 자식 클래스는 부모 클래스의 행위를 일관되게 유지해야 하며, 부모 클래스로 선언된 객체를 자식 클래스로 치환해도 프로그램의 행동이 변하지 않아야 한다
public class Bird {
public void fly() {
System.out.println("Bird is flying");
}
}
public class Ostrich extends Bird {
@Override
public void fly() {
throw new UnsupportedOperationException("Ostrich can't fly");
}
}
타조는 날 수 없기 때문에 부모 클래스인 Bird의 행위를 위반하게 된다 이는 LSP를 위반한다.
- 인터페이스 분리 원칙(ISP: Interface Segregation Principle)
원칙: 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하지 않아야 한다.
-> 특정 클래스가 사용하지 않는 메서드를 강제로 구현하게 하지 말아야 한다.
-> 인터페이스를 세분화하여 필요한 부분만 구현하도록 해야 한다.
public interface Worker {
void work();
void eat();
}
public class HumanWorker implements Worker {
public void work() {
// 일하는 로직
}
public void eat() {
// 밥 먹는 로직
}
}
public class RobotWorker implements Worker {
public void work() {
// 일하는 로직
}
public void eat() {
// 로봇은 밥을 먹지 않으므로 문제 발생
}
}
위의 코드철머 큰 인터페이스를 구현하면 모든 메서드를 구현해야 하므로 문제가 될 수 있다.
public interface Workable {
void work();
}
public interface Eatable {
void eat();
}
public class HumanWorker implements Workable, Eatable {
public void work() {
// 일하는 로직
}
public void eat() {
// 밥 먹는 로직
}
}
public class RobotWorker implements Workable {
public void work() {
// 일하는 로직
}
}
- 의존 역전 원칙(DIP: Dependency Inversion Principle)
원칙: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다.
-> 구체적인 구현체에 의존하지 말고, 추상화된 인터페이스나 부모 클래스에 의존해야 한다.
Servlet
서블릿은 Java를 기반으로 한 웹 애플리케이션을 개발하기 위한 서버 측 컴포넌트이다. 주로 HTTP 요청을 처리하고, 그에 대한 응답을 생성하는 역할을 한다. 서블릿은 자바 인터페이스로, 웹 서버에서 실행되며 동적인 웹 페이지를 생성하는 데 사용된다.
서블릿의 주요 기능
- HTTP 요청 처리: 클라이언트로부터 들어온 요청을 받아 처리하고, 적절한 응답을 생성한다.
- 동적 콘텐츠 생성: 요청에 맞는 동적인 웹 페이지나 데이터를 생성해 클라이언트로 전송한다
- 상태 관리: 세션, 쿠키 등을 이용해서 클라이언트의 상태를 관리할 수 있다.
@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("<h1>Hello, World!</h1>");
}
}
ServletContainer
서블릿 컨테이너는 서블릿의 실행 환경을 제공하는 소프트웨어이다. 일반적으로 웹 애플리케이션의 서버(WAS)의 일부로 존재하며, 서블릿의 생명주기 관리, 요청 및 응답 처리, 세션 관리등의 기능을 수행한다.
서블릿 컨테이너의 역할
- 서블릿 관리: 서블릿의 생성, 초기화, 실행, 종료를 포함한 생명주기 관리
- HTTP 요청 및 응답 처리: 클라이언트로부터 HTTP 요청을 받아 적절한 서블릿에 전달하고, 서블릿의 응답을 클라이언트로 전달
- 멀티스레드 지원: 하나의 서블릿이 여러 클라이언트 요청을 동시에 처리할 수 있도록 스레드를 관리
- 세션 관리: 클라이언트의 상태를 유지하기 위해 세션 및 쿠키를 관리
서블릿 컨테이너로는 Apache Tomcat, Jetty, Undertow 등이 있다.
WAS VS 서블릿 컨테이너
WAS는 웹 서버 기능뿐만 아니라 비즈니스 로직을 처리하는 애플리케이션 서버이다. 즉, WAS는 서블릿 컨테이너뿐만 아니라 EJB 컨테이너와 같은 더 복잡한 애플리케이션 로직을 처리할 수 있는 다양한 모듈을 퐇마한다. WAS는 데이터베이스와 연동하거나, 트랜잭션 관리, 분산 컴퓨팅, 보안 등을 처리할 수 있는 기능을 제공한다.
WAS의 주요기능
- 서블릿, JSP 실행: 서블릿 컨테이너 역할
- 비즈니스 로직 처리: EJB(Enterprise JavaBeans) 등 복잡한 비즈니스 로직을 처리
- 트랜잭션 관리: 여러 데이터베이스 작업이나 비즈니스 로직 실행 간의 트랜잭션 관리
- 자원 관리: 연결 풀링, 데이터베이스 연결, 메시징 시스템 등을 관리
- 보안: 인증 및 인가, SSL 지원 등을 통해 보안을 강화
서블릿 컨테이너는 서블릿과 JSP를 실행하는 환경을 제공하는 서버이고, 주로 HTTP 요청과 응답을 처리한다.
WAS는 서블릿 컨테이너의 기능을 포함하면서 더 복잡한 비즈니스 로직 처리, 트랜잭션 관리 등 다양한 기능을 제공하는 웹 애플리케이션 서버이다.
Dispatcher Servlet
디스패처 서블릿이란 Servlet의 일종이다.
public class DispatcherServlet extends FrameworkServlet {
}
public abstract class FrameworkServlet extends HttpServletBean {
}
public abstract class HttpServletBean extends HttpServlet {
}
가장 먼저 요청을 받고, 적절하게 처리할 함수(컨트롤러)를 찾아서 정해주는 역할을 한다.
과거에는 모든 서블릿을 URL 매핑을 위해 web.xml에 등록해야 했지만, 디스패처 서블릿을 통해 해결할 수 있다.
디스패처 서블릿은 스프링 MVC의 중앙 서블릿이며 어플리케이션으로 오는 모든 요청을 핸들링하고 공통작업을 처리해준다. -> 이처럼 서블릿 컨테이너 맨 앞에서 모든 요청을 받아 처리해주는 컨트롤러로 프론트 컨트롤러 패턴이라고 한다.
서블릿은 스스로 동작하지 않는다. 보통 서블릿을 관리할 톰캣 등과 같은 서블릿 컨테이너를 사용한다.
서블릿 컨테이너는 싱글톤인 서블릿 객체의 생명주기를 관리한다. 또한 웹서버와 소켓으로 통신하며, 클라이언트의 요청을 받고 응답을 보내준다.
MVC란
MVC 는 Model, View, Controller의 약자 입니다. 하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴입니다.
모델은 컨트롤러에 컨트롤러는 뷰에 뷰는 다시 유저 유저는 다시 컨트롤러를 향해서 갑니다.
모델, Model
애플리케이션의 정보, 데이타를 나타냅니다. 데이타베이스, 처음의 정의하는 상수, 초기화값, 변수 등을 뜻합니다. 또한 이러한 DATA, 정보들의 가공을 책임지는 컴포넌트를 말합니다.
이 모델은 다음과 같은 규칙을 가지고 있습니다.
- 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
즉, 화면안의 네모박스에 글자가 표현된다면, 네모박스의 화면 위치 정보, 네모박스의 크기정보, 글자내용, 글자의 위치, 글자의 포맷 정보 등을 가지고 있어야 한다는 것입니다.
- 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.
데이터 변경이 일어났을 때 모델에서 화면 UI를 직접 조정해서 수정할 수 있도록 뷰를 참조하는 내부 속성값을 가지면 안 된다는 말입니다.
- 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.
모델의 속성 중 텍스트 정보가 변경이 된다면, 이벤트를 발생시켜 누군가에게 전달해야 하며, 누군가 모델을 변경하도록 요청하는 이벤트를 보냈을 때 이를 수신할 수 있는 처리 방법을 구현해야 합니다. 또한 모델은 재사용가능해야 하며 다른 인터페이스에서도 변하지 않아야 합니다.
뷰, View
input 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타냅니다. 다시 말해 데이터 및 객체의 입력, 그리고 보여주는 출력을 담당합니다. 데이타를 기반으로 사용자들이 볼 수 있는 화면입니다.
뷰에서는 다음과 같은 규칙들이 있습니다.
- 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
화면에 글자를 표시 하기 위해, 모델이 가지고 있는 정보를 전달받게 될텐데, 그 정보를 유지하기 위해서 임의의 뷰 내뷰에 저장하면 안됩니다. 단순히 네모 박스를 그리라는 명령을 받으면, 화면에 표시하기만 하고 그 화면을 그릴 때 필요한 정보들은 저장하지 않아야 합니다.
- 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 된다.
모델과 같은 자기 자신의 빼고는 다른 요소는 참조하거나 어떻게 동작하는지 알아서는 안됩니다. 그냥 뷰는 데이터를 받으면 화면에 표시해주는 역할만 가진다고 보면 됩니다.
- 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.
모델과 같이 변경이 일어났을 때 이른 누군가에게 변경을 알려줘야 하는 방법을 구현해야 합니다. 뷰에서는 화면에서 사용자가 화면에 표시된 내용을 변경하게 되면 이를 모델에게 전달해서 모델을 변경해야 할 것이다. 그 작업을 하기 위해 변경 통지를 구현합니다.
그리고 재사용가능하게끔 설계를 해야 하며 다른 정보들을 표현할 때 쉽게 설계를 해야 합니다.
컨트롤러,Controller
데이터와 사용자인터페이스 요소들을 잇는 다리역할을 합니다.
즉, 사용자가 데이터를 클릭하고, 수정하는 것에 대한 "이벤트"들을 처리하는 부분을 뜻합니다.
컨트롤러 또한 다음과 같은 규칙을 이해해야 합니다.
- 모델이나 뷰에 대해서 알고 있어야 한다.
모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고, 수신하는 방법만 가지고 있는데 이를 컨트롤러가 중재하기 위해 모델과 그에 관련된 뷰에 대해서 알고 있어야 합니다.
- 모델이나 뷰의 변경을 모니터링 해야 한다.
모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지를 해야 합니다.
또한, 애플리케이션의 메인 로직은 컨트롤러가 담당하게 됩니다.
왜 MVC패턴을 사용해야 할까.
사용자가 보는 페이지, 데이터처리, 그리고 이 2가지를 중간에서 제어하는 컨트롤, 이 3가지로 구성되는 하나의 애플리케이션을 만들면 각각 맡은바에만 집중을 할 수 있게 됩니다. 공장에서도 하나의 역할들만 담당을 해서 처리를 해서 효율적이게 됩니다. 여기서도 마찬가지입니다.
- 사실 저 밑에 스즈키 네는 군용 볼트를, 옆집 하루노보 네는 군용 너트를 만들고 있을 뿐이다.
(커티스 르메이, 도쿄 대공습 직전에 부하들에게.)
서로 분리되어 각자의 역할에 집중할 수 있게끔하여 개발을 하고 그렇게 애플리케이션을 만든다면, 유지보수성, 애플리케이션의 확장성, 그리고 유연성이 증가하고, 중복코딩이라는 문제점 또한 사라지게 되는 것입니다. 그러기 위한 MVC패턴입니다.
*유연성: 여기서 유연성이라는 것은 클라이언트의 새로운 요구사항에 대해 최소한의 비용으로 보다 유연하게 대처할 수 있는 것을 말합니다.
*비즈니스로직: 프로그램의 논리구조
