1. 프록시 패턴과 프록시 서버
프록시를 번역하면 대리자, 대변인의 의미를 갖고 있다. 대리자, 대변인은 누군가를 대신해서 그 역할을 수행하는 존재이다. 이는 프로그램에도 똑같이 적용된다. 즉, 프록시에게 어떤 일을 대신 시키는 것이다.
💡 프록시 패턴이란?
프록시의 의미처럼 객체를 사용하고자 할 때, 객체를 직접적으로 참조하는 것이 아니라, 해당 객체를 대행하는 객체를 통해 대상 접근하는 방식을 사용한다.
그러면 해당 객체가 메모리에 존재하지 않아도 기본적인 정보를 참조하거나 설정할 수 있고, 또한 실제 객체의 기능이 반드시 필요한 시점까지 객체의 생성을 미룰 수 있다.
✅ 프록시 패턴 장점
- 사이즈가 큰 객체(ex: 이미지)가 로딩되지 전에도 프록시를 통해 참조를 할 수 있다.
- 실제 객체의 public, protected 메소드들을 숨기고 인터페이스를 통해 노출 시킬 수 있다.
- 로컬에 있지 않고 떨어져 있는 객체를 사용할 수 있다.
- 원래 객체의 접근에 대해서 사전처리를 할 수 있다.
✅ 프록시 패턴 단점
- 객체를 생성 할 때 한단계를 거치게 되므로, 빈번한 객체 생성이 필요한 경우 성능이 저하 될 수 있다.
- 프록시 내부에서 객체 생성을 위해 스레드가 생성, 동기화가 구현되야 하는 경우 성능이 저하될 수 있다.
- 로직이 난해해져 가독성이 떨어질 수 있다.
💡프록시 서버란?
프록시 서버는 인터넷에서 유저를 대신해서 데이터를 가져오는 서버이다.
원래는 클라이언트가 서버에 직접 접근해서 요청한 내용을 가져와야 하지만 프록시 서버가 대신 서버에 요청하고 클라이언트에게 가져다 준다.
2. 이터레이터 패턴 (iterator pattern)
💡 이터레이터 패턴이란?
이터레이터를 사용하여 컬렉션의 요소들에 접근하는 디자인패턴
행위 패턴으로 컬렉션 구현 방법을 노출 시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 수 있게 해주는 방법을 제공해주는 패턴이다.
이터레이터 패턴을 사용하면 집합체 내에서 어떤 식으로 일이 처리되는지 몰라도 그 안에 들어있는 항목들에 대해서 반복작업을 수행할 수 있다.
✅ 이터레이터 패턴의 장점
- 집합체 클래스의 응집도를 높여준다.
- 집합체 내에서 어떤 식으로 일이 처리되는지 알 필요 없이, 집합체 안에 들어있는 모든 항목에 접근할 수 있게 해준다.
- 모든 항목에 일일이 접근하는 작업을 컬렉션 객체가 아닌 이터레이터 객체에서 맡게 된다. 이렇게 하면, 집합체의 인터페이스 및 구현이 간단해질 뿐만 아니라, 집합체에서는 반복 작업에서 손을 뗴고 원래 자신이 할 일에만 전념할 수 있다.
✅ 이터레이터 패턴의 단점
- 단순한 순회를 구현하는 경우 클래스만 많아져 복잡도가 증가 할 수 있다.
3. 노출모듈 패턴
💡 노출모듈 패턴이란?
노출 모듈 패턴은 즉시 실행 함수를 통해 pirvate, public과 같은 접근 제어자를 만드는 패턴을 만한다.
💡 즉시실행함수란?
함수를 정의, 변수에 함수를 저장, 실행의 과정이 아닌 함수를 정의하자 마자 바로 호출하는 함수이다. 초기화 코드 , 라이브러리 내 전역 변수의 충돌 방지 등에 사용한다.
✅ 노출모듈 패턴의 장점
- 개발자에게 깔끔한 접근 방법을 제공한다.
- private 데이터 제공
- 전역변수를 덜 더럽히며 사용한다.
- 클로저를 통해 함수와 변수를 지역화한다.
- 스크립트 문법이 일관성있다.
- 명시적으로 public 메소드와 변수를 제공해 명시성을 높인다.
✅ 노출모듈 패턴의 단점
- private 메소드 접근할 방법이 없다.
- private 메소드에 대해 함수를 확장하는데 어려움이 있다.
- private 메소드를 참조하는 public 메소드를 수정하기 어렵다.
4. MVC 패턴
모델-뷰-컨트롤러는 소프트웨어 디자인 패턴으로 애플리케이션의 구성요소를 세가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발 할 수 있다.
재사용성과 확장성이 용이하다는 장점이 있고, 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점이 있다.
💡 모델 Model
- Data와 애플리케이션이 무엇을 할 것인지를 정의하는 부분으로 내부 비즈니스 로직을 처리하기 위한 역할을 한다.
- 즉, 모델은 컨트롤러가 호출하면 DB와 연동하여 사용자의 입출력 데이터를 다루는 일과 같은 데이터와 연관된 비즈니스 로직을 처리하는 역할을 한다.
- 데이터 추출, 저장, 삭제, 업데이트 등의 역할을 수행한다.
📌 모델의 규칙
- 사용자가 편집하기를 원하는 모든 데이터를 가지고 있어야 한다.
- 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야한다.
- 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.
💡 뷰 View
- 뷰는 사용자에게 보여주는 화면 UI가 해당된다.
- 사용자와 상호작용을 하며 컨트롤러로부터 받은 모델의 결과값을 사용자에게 화면으로 출력하는 일을 한다.
- MVC에서는 여러개의 View가 존재할 수 있다.
- 모델에서 받은 데이터를 별도로 저장하지 않는다.
📌 뷰의 규칙
- Model이 가지고 있는 정보를 따로 저장해서는 안된다.
- 모델이나 컨트롤러와 같이 다른 구성 요소들을 몰라야 한다.
- 변경이 일어나면 변경 통지에 대한 처리 방법을 구현해야만 한다.
- 특히 모델과 뷰는 서로의 존재를 몰라야 한다.
💡 컨트롤러 Controller
- 컨트롤러는 모델과 뷰 사이를 이어주는 인터페이스 역할을 한다.
- 즉, 모델이 데이터를 어떻게 처리할지 알려주는 역할을 한다.
- 사용자로부터 뷰에 요청이 있으면 컨트롤러는 해당 업무를 수행하는 모델을 호출하고 모델이 업무를 모두 수행하면 다시 결과를 뷰에 전달하는 역할을 한다.
📌 컨트롤러의 규칙
- 모델이나 뷰에 대해서 알고 있어야 한다.
- 모델이나 뷰의 변경사항을 모니터링 해야 한다.
✅ MVC의 장점
- 기능별로 코드를 분리하여 하나의 파일에 코드가 모이는 것을 방지하여 가독성과 코드의 재사용성이 증가한다.
- 각 구성요소들을 독립시켜 협업을 할 때 맡은 부분의 개발에만 집중 할 수 있어 개발의 효율성을 높여준다.
- 개발 후에도 유지보수성과 확장성이 보장된다.
✅ MVC의 한계
- 모델과 뷰는 서로의 정보를 갖고 있지 않는 독립적인 상태라고 하지만 모델과 뷰 사이에는 컨트롤러를 통해 소통을 이루기때문에 의존성이 완전히 분리 될 수 없다. 그래서 복잡한 대규모 프로그램의 다수의 뷰와 모델이 컨트롤러를 통해 연결되기 때문에 컨트롤러가 불필요하게 커지는 현상이 발생하기도 한다.
