CS 전공지식 노트

진행 방식 : 6명의 구성원들로 구성 , 주1회 1시간씩 진행

                 6주치 발표 순서를 정하고, 매 주 소단원5개 공부 후 발표자 1명 , 청중5명으로 배정

                 발표가 끝난 후에는 예상 면접질문,궁금증에 대해 얘기한다.

 

 

처음부터 깊게 코드의 내용을 이해하기보다는 각 패턴에 대한 컨셉과 내용을 이해해보기로 했다

CHAPTER 1. 디자인 패턴과 프로그래밍 패러다임

- SECTION1 디자인패턴

 

디자인 패턴이란 기존 환경 내에서 반복적으로 일어나는 문제들을 해결 할 때 참고 할 수 있는 해결방식

 

 

어떤 문제나 궁금증이 생겼을 때 매번 누군가의 코드를 보고 설명하면 비효율적이지 않을까?

반복적이고 똑같은 문제들을 정리하고 공유하면 커뮤니케이션 비용도 줄어들고 문제 해결도 효율적이지 않을까 ?

 

 

반복되는 문제가 생겼을 때

 

00패턴으로 해결하면 어때요? -> 아 00패턴이요? 

라고 하면 훨씬 더 커뮤니케이션이 효율적이고 문제 해결도 더 효과적이다 

그런 방법을 정리해놓은게 디자인 패턴이 탄생한것이라 추측해본다.

 

 

 

 

1. 싱글톤 패턴

 

하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴

 

장점 
하나의 인스턴스를 공유하기 때문에 생성에  드는 비용이 줄어드는 장점

단점
- 싱글톤 패턴의 단점 
하나의 인스턴스를 공유하기 때문에  각 테스트마다 독립적인 환경을 구성하기가 어렵다는 단점

 하나의 인스턴스에 의존성이 높아진다는 단점

의존성 주입을 통해 모듈간의 연관관계를 느슨하게 만들어 해결한다.

 

내 생각

자바,스프링을 사용하는 입장에서 스프링 프레임워크는 싱글톤이 기본설정이다.

@ComponentScan을 통해 IOC컨테이너에 Bean들이 등록되고 싱글톤으로 관리되는  Bean들을

DI를 통해  모두 공유해서 쓴다

싱글톤패턴은 IOC와 DI로 연결되는 스프링의 중요 핵심 개념이고

현재 이유를 불문하고 현재 단점을 뛰어넘을 정도로 뛰어난 장점을 가진 것이라고 생각한다.

 

 

기본 바탕으로 스프링이 돌아가기 때문에  싱글톤 패턴을 사용함으로 얻는 이점은 베이스로 깔고 가고싱글톤

패턴을 쓰지 말아야할 때는 언제인지? 에 대해 초점을 맞춰 공부하는게 더 효율적일것같다.

 

 

 

 

 

 

 

 

 

 

 

2. 팩토리 패턴

???

객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴이자 상속관계에 있는 두 클래스에서
상위 클래스가 중요한 뼈대를 결정하고 하위 클래에서 객체 생성에 관한 구체적인 내용 결정

상위 클래스와 하위 클래스가 분리되기 때문에 느슨한 결합을 가지며, 상위 클래스에서는 인스턴스 생성
방식에 대하여 전혀 알  필요가 없기 때문에 더 많은 유연성을 갖게 된다.

객체 생성 로직이 따로 떼어져있기때문에 코드를 리팩토링하더라도 한곳만 고칠수 있게 되니
유지보수성이 증가한다 .


???
무슨 소리지 

그래도 내가 아는 예시가 있지 않을까??  

스프링프레임워크에서 Factory패턴이 아니더라도 Factory라는 것을  사용해본적이 있나??

스프링에는 없던거 같은데  

그러다 문득 드는 생각이 JPA의EntityManagerFactory였다

public class JpaFactoryExample {
    public static void main(String[] args) {
        // EntityManagerFactory 생성
        EntityManagerFactory emf = Persistence.createEntityManagerFactory("example-unit");
        
        // EntityManager 생성
        EntityManager em = emf.createEntityManager();
        
        // 비즈니스 로직 수행
        em.getTransaction().begin();
        // 엔티티 작업 수행
        em.getTransaction().commit();
        
        // 리소스 해제
        em.close();
        emf.close();
    }
}

 

JPA의 작동을 위해서는 EntityManagerFactory라는 Application에서 1개뿐인 객체를 생성해야한다.

생성된 EntityManagerFactory로 EntityManager를 생성하고 EntityTransaction을 만들어 작동한다.

Persistence의 팩토리 메소드는 EntityManager를 반환하는데 나는 어떻게 생성되는지 알지 못하고 그저 메소드를 호출할 뿐이다.

그러면 EntityManagerFactory를 구현한 객체가 만들어져서 나오는 것이다 

 

내 생각 

처음에는 막막해 보이던 개념도 오히려 내가 썼던 것중에 없을까? 내가 아는것중에 없을까?

생각 한 후에 내가 공부한 개념을 적용시켜보니까

책에 있는 예시나 구글링을 통해 얻은 예시보다 더 효과적으로 이해되었다

내가 아는 지식에서 찾아보고 없으면 구글링,검색을 하는게 효과적인 학습법 

 

 

 

 

 

 

 

3. 전략 패턴

객체의 행위를 바꾸고 싶은 경우 직접 수정하지 않고 전략이라고 부르는 캡슐화한 알고리즘을 
컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴 
 전략패턴은 메서드(알고리즘) 재사용이고 의존성 주입은 객체 재사용이다. 

 

public class StrategyPatternExample {
    public static void main(String[] args) {
        Printer printer = new Printer();

        // 대문자로 출력하는 전략 설정
        printer.setStrategy(new UpperCasePrintStrategy());
        printer.print("Hello, World!");

        // 소문자로 출력하는 전략 설정
        printer.setStrategy(new LowerCasePrintStrategy());
        printer.print("Hello, World!");
    }
}

자세한 코드보다 흐름을 설명하면 

Printer 객체에 Strategy 설정에 따라 객체가 설정되고 ,

그에 따른 인터페이스를 구현한 클래스의 메서드가 달라져  

똑같은 문자("Hello world") 를 줘도 출력결과가 달라지게 된다 

 

 

 

내 생각 

뭔가 DI랑 비슷한거 같으면서도 다른 느낌이다

DI는 구현 객체 클래스의 타입이 같으면 클래스가 구현한 인터페이스로 특정하지 못하여 따로 설정해줘야 해서

구현 클래스가 많아지면 무엇이 DI가  되었는지 확인해봐야 하지만

전략패턴 같은경우는 호출 할 때 사용할 전략(객체)를 지정해 주기 때문에 무엇이 들어갔는지 확실하게 알 수 있는 장점이 있는것같다.

 

DI는 IOC컨테이너에 의해 싱글톤으로 관리될 필요가 있을 경우에!

전략 패턴은 말그대로 싱글턴으로 관리될 필요 없고 상황에 따라 생성되는 경우!에 사용하면 좋을것 같다 

 

 

 

 

 

 

 

 

 

 

4. 옵저버 패턴

주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해
옵저버 목록에 있는 옵저버들에게 변화를 알려준다

 

주체 : 객체의 상태 변화를 보고 있는 관찰자
옵저버 : 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 추가 변화 사항이 생기는 객체들을 의미

 

 

 

 

 

 

 

5. 프록시 패턴과 프록시 서버

대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 해당 접근을 필터링하거나 
  수정하는 등의 역할을 하는 계층이 있는 디자인 패턴
객체의 속성 변환 등을 보완하며 보안,데이터 검증,캐싱 , 로깅 등에 사용한다.

CORS와 프론트엔드의 프록시 서버

CORS(Cross origin resource sharing) -> 서버가 웹 브라우저에서 리소스를 로드할 때 다른 오리진을 통해

로드하지 못하게 하는 HTTP헤더 기반 메커니즘.

 

sop(same origin policy) -> 웹 브라우저는 기본적으로 sop를 따르는데 이는 똑같은 오리진끼리만 송수신 할 수 있다는 것이다.
프론트엔드개발 시 프런트엔드 서버를 만들어서 백엔드 서버와 통신할 때 주로 cors를 마주치는데
이를 해결하기 위해 프런트엔드에서 프록시 서버를 만들기도 한다.

 

프록시 서버란?-> 프록시 서버는 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 

서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램.

 

Origin ( 프로토콜,호스트이름,포트의 조합) 

http://localhost:8080/student/100 -> 백엔드 서버

위의 보라색 부분이 Origin이다

http://localhost:3000 -> 프론트엔드 서버

 

이 때 3000번에서 8080번으로 요청을 한다면 sop 위반으로 요청이 되지 않는다.

 

이 때 프록시서버를 둬서 프런트엔드 서버에서 요청되는 오리진을 localhost:8080으로 바꾼다.

 

그러나 프론트엔드에서 설정하기보다는 서버에서 cors +origin 설정을 하는게 나은 방법이다.

 

 

 

 

내 생각 

스프링부트(백엔드) 단에서만 일어나는 일이 아닌 서버나 프론트엔드쪽과 연결될 때

발생하는 문제들에 대해 항상 겁이 났다.

외계어 같기도 하고 내가 잘 모르는 분야같다고 생각이 들어 일단 피한 경향이 있었고 

 Cors나 sop나 proxy Server에 대해 드문드문 들어봤는데 항상 두려움이 있다.

Proxy라는 개념은 자바,스프링,JPA,서버에서도 자주 보이는 개념이었는데 한번 정리하는 시간을 가져야 할것 같다.