본문 바로가기

웹 프로그래밍

 (63)
싱글톤 패턴 왜 싱글톤? -(기존) 클라이언트가 요청할때마다 객체가 생성 -> 메모리 낭비 -해결책: 해당 객체를 한개만 생성하고 공유하도록 설계 -클래스의 인스턴스가 딱 1개만 생성되는것을 보장하는 디자인 패턴 -e.g. static 영역에 객체 instace를 미리하나 생성하고 getInstance()메서드를 통해서만 조회 -생성자를 private 막아서 new 키워드로 객체 인스터스가 생성되는것을 막음 -하나의 객체만을 쓰기 때문에 시스템 효율증가 -단점 - DIP 위반(클라이언트가 구체 클래스에 의존) e.g. 구체클래스.메서드() - OCP 위반 - 테스트하기 어려움(설정이 이미 끝남) - 유연성이 떨어짐 싱글톤 컨테이너 -싱글톤 패턴의 모든 문제점을 해결하면서 객체 인스턴스를 싱글톤으로 관리(스프링 빈 객..
스프링 컨테이너와 스프링 빈 스프링 컨테이너 -ApplicationContext는 인터페이스이며 스프링 컨테이너임 -new AnnotationConfigApplicationContext(AppConfig.class); 에서 AppConfig.class로 구성정보 지정 스프링 컨테이너 안 스프링 빈 저장소 빈 이름(key) 빈 객체(value) AppConfig.class 클래스 정보를 사용해서 @Bean이 붙은 메세드를 호출하여 스프링 빈 등록(네임, 객체) 스프링 컨테이너는 설정정보를 참고해서 의존관계를 주입(DI) 스프링 빈의 라이프 사이클 -객체생성 단계 -> 의존관계 주입 단계 (예외, 생성자 주입은 객체생성때 의존관계 주입) 스프링 빈 조회-상속관계 -부모 타입으로 조회하면, 자식 타입도 함께 조회함(다 끌고옴) -e.g...
IoC, DI, 컨테이너 제어의 역전 IoC(Inversion of Control) -(기존) 구현체가 프로그램의 제어 흐름을 스스로 조종 -> AppConfig가 모든 제어 흐름의 권한을 가짐 -프로그램의 제어 흐름을 직접 제어가 아닌 외부에서 관리하는것을 제어의 역전이라 함 -작성한 코드를 제어하고 대신 실행 -> 프레임 워크(JUnit) -개발자가 작성한 코드가 직접 제어 흐름을 담당 -> 라이브러리 의존관계 주입 DI -실행 시점에 외부에서 실제 구현체를 생성하고 클라이언트에 전달해서 서버와의 실제 의존관계가 연결되는것 -정적인 클래스 의존관계: 애플리케이션 실행하지 않고 분석가능(클래스 다이어그램) -정적인 클래스 만으로는 실제 어느 구현체를 사용했는지 알수없음 -동적인 객체 인스턴스 의존관계: 애플리케이션 실행 시점에..
AppConfig AppConfig 인터페이스 뿐만아니라 구현체까지 의존하는 문제를 어떻게 해결할까? (DIP 위반) -> 애플리케이션의 전체 동작 방식을 설정(config)하기 위해 구현 객체를 생성하고 연결해주는 책임을 가지는 설정클래스를 만듦 생성자 주입: 생성자를 통해서 구현체를 넣어줌 -> 클라이언트는 인터페이스만 의존함 DI(Dependency Injection) 의존관계 주입: 클라이언트 입장에서는 마치 외부에서 의존관계를 주입해주는것 처럼 보임 AppConfig에서는 역할과 구현 클래스가 한눈에 들어옴(설계도), 사용영역의 코드는 바꾸지 않고 구성영역의 코드만 자유롭게 교체가능 좋은 객체 지향 설계의 5가지 원칙 적용 -SRP: 클라이언트 객체는 실행하는 책임, AppConfig는 구현체 생성과 연결하는 책..
좋은 객체 지향 설계의 5가지 원칙(SOLID) SOLID -SRP(Single responsibility principle) 단일 책임 원칙 -중요한 기준은 변경임(변경시 파급효과가 적어야함) -OCP(Open/Closed principle) 개방-폐쇄 원칙 -확장에는 열려있으나 변경에는 닫혀있음(역할과 구현) -그러나 구현 객체를 변경하려면 클라이언트 코드를 변경해야함(OCP 위반) -LSP(Liskov substitution principle) 리스코프 치환 원칙 -인터페이스 규약,의도 맞게 구현 -ISP(Interface segregation principle) 인터페이스 분리 원칙 -범용 인터페이스 하나보다 여러개의 인터페이스가 더 좋음(독립, 명확, 대체가능성) -DIP(Dependency inversion principle) 의존관계 역전..
객체 지향 프로그래밍 객체 지향 프로그래밍 -프로그램을 객체들의 모임으로 파악(즉 객체(클라이언트, 서버)간의 협력) -> 유연, 변경 용이(다형성) 다형성 -역할(인터페이스)과 구현(구현 객체)을 분리 -클라이언트는 대상의 인터페이스만 알면 됨 -클라이언트는 구현대상의 변화에 영향을 받지 않음(클라이언트의 편의성 증가) -구현보다 역할에 포커스(무한대로 확장 가능) 다형성의 본질 -구현 객체 인스턴스를 실행 시점에 유연하게 변경가능 -클라이언트를 변경하지 않고, 서버 구현 기능을 유연하게 변경가능 한계 -역할(인터페이스)가 바뀌면, 클라이언트, 서버에 큰 변경이 발생 -따라서 인터페이스를 안정적으로 설계하는것이 중요 스프링과 객체 지향 -제어의 역전(IoC), 의존관계 주입(DI)은 다형성을 활용하여 역할과 구현을 편리하게..
스프링 이란? 스프링 프레임워크 -핵심 기술: 스프링 DI 컨테이너, AOP, 이벤트, 기타 -웹 기술: 스프링 MVC, 스프링 WebFlux -데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원 -기술 통합: 캐시, 이메일, 원격접근, 스케줄링 -테스트: 스피링 기반 테스트 지원 -언어: 코틀린, 그루비 - 최근에는 스프링 부트를 통해서 스프링 프레임워크의 기술들을 편리하게 사용 스프링 부트 -스프링을 편리하게 사용할수 있도록 지원(실무에서는 기본) -Tomcat 내장, 단독으로 실행할수 있는 스프링 애플리케이션을 쉽게 생성 -starter 종속성 제공(예를 들어 라이브러리 한개만 땡기면 알아서 다 땡껴준다) -외부 라이브러리 버전을 자동으로 선정 -메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비..

티스토리툴바