본문 바로가기
📖 나의 개발일지 (WIL&TIL)

[TIL] 오늘의 개발일지

by 따따시 2023. 3. 30.

오전엔 미니플젝 그저께 서버 연결 get, post 성공했던 작업 후로 회원가입 요청을 보내는 걸 구현했다

구현은 했는데....(ㅅㅁ아 컴퓨터 켜줘 ❤️)

아무래도 주말에 다같이 모여서 또 한판 작업을 하면 넘 재밌겠다는 생각 >_<

 

오늘부터 알고리즘 강의를 들으면서 CS책도 읽기 시작했는데, 아직은 용어가 완전 낯설지만

낯선거지 어려운게 아닐 거라는 생각을 하면서 내가 제일 잘하는 것 중 하나인 '익숙해지기' 권법을(?) 써야지

CS책 읽으면서 복습할 겸 다시 한번 정리하는 디자인 패턴 중 싱글톤 패턴에 관한 내용 정리

(사실 읽는데 뭔놈의 새로운 용어가 이렇게 많고, 처음 중국어 배웠을때 들리는 느낌 ^^ 어쩌겠어 친해져야지)

 

디자인 패턴??

- 디자인 패턴은 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계를 이용하여 해결할 수 있도록 하나의 '규약'형태로 만들어 놓은 것

 

(1) 싱글톤 패턴

싱글톤 패턴은 하나의 클래스에 오직 '하나의 인스턴스'만 가지는 패턴이다.

하나의 인스턴스를 만들어놓고 해당 인스턴스를 다른 모듈들이 공유하면서 사용하기 때문에 인스턴스 생성 비용이 줄어들지만, 의존성이 높아진다는 단점이 있다.

 

* 자쓰에서 싱글톤 패턴

js에서는  { } 이나 new Object를 이용해서 객체를 생성하면 다른 어떤 객체와도 같지 않기 땜에 이 자체만으로 싱글톤 패턴이 된다.

(그거자넝, 원시 타입 말고는 다 참조 타입인데 참조타입은 주솟값이 저장되자너 , 옵줵의 데이터는 별도 메모리 공간(heap)에 저장되고, 변수에 할당할 땐 요  힙(Heap) 메모리의 주소값이 저장!)

const a = { a : 1 } ;
const b = { a : 1 } ;
console.log(a==b) // 결과값:false

 

* 잠깐, 인스턴스 용어 확실히 알고있니?

비슷한 성질을 가진 여러개의 객체를 만들기 위해,

일종의 '설계도'라고 할 수 있는 생성자 함수(Constructor)를 만들어 붕어빵을 찍어내는데 이렇게 생성된 객체가 인스턴스임

 

 

요 싱글톤 패턴은 데이터베이스 연결 모듈에 많이 쓰인다.

const URL = 'mongodb://localhost:27017/hong'
const createConnection = url => ({"url":url})
class DB {
	constructor(url){
    		if(!DB.instance){
            		DB.instance=createConnection(url)
            }
            return DB.instance
    }
    connect( ) {
    	return this.instance
    }
 }
 
 const a = new DB(URL);
 const b = new DB(URL);
 console.log(a===b); // 결과값 : true

보면 DB.instance라는 하나의 인스턴스로 a,b를 찍어내고 있음 -> db연결에 관한 인스턴스 생성 비용을 아낀것

 

그럼, 싱글톤 패턴의 단점??

싱글톤 패턴은 TDD(Test Driven Development)를 할때 걸림돌이 되는데, TDD를 할때 단위 테스트를 주로 하는데 단위 테스트는 테스트가 서로 독립적이어야 하고 테스트를 어떤 순서로든 실행시킬 수 있어야 하는데 싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴이다보니 각 테스트마 독립적인 인스턴스를 만들기가 어렵다고 한당

 

또, 모듈 간의 결합을 강하게 만들 수 있다는 단점이 있는데

이는 의존성 주입(DI, Dependency Injection)을 통해 모듈 간의 결합을 좀 더 느슨하게 만들어 해결할 수 있다.

메인 모듈이 직접 다른 하위 모듈에 의존성을 주기보단 중간에 '의존성 주입자'(dependency injector)가 중간에 낑겨들어서 메인 모듈을 간접적으로 의존성 주입하는 방식을 말함

 

의존성 주입의 장점?

모듈들을 쉽게 교체할 수 있는 구조가 되서 테스팅하기가 쉽고, 마이그레이션(한 시스템에서 다른 시스템으로 이동하는 것)하기도 수월해진다고 한다. 또 구현할 때 추상화 레이어를 넣고 이를 기반으로 구현체를 넣어주기 때문에 애플리케이션 의존성 방향이 일관되고 애플리케이션을 쉽게 추론할 수 있으며 모듈 간의 관계가 명확해진다고 함

 

의존성 주입의 단점?

모듈들이 더 분리가 되서 클래스 수가 늘어나 복잡성이 증가될 수 있고 약간의 런타임 패널티가 생기기도 한다고 한다.

 

* 의존성 주입의 원칙의존성 주입은 "상위 모듈을 하위 모듈에서 어 어떠한 것도 가져와선 안된다"또한, 둘 다 추상화에 의존해야 하며, 이때 추상화는 세부사항에 의존하지 말아야 한다고 한다.

 


생리해서 컨디션도 좋지 않은데 많은 것들을 해내느라 고생하고 있따 기특한 내 자신

오늘은 기특한 내 자신을 위해 일찍 자고 달다구리한 걸로 보상을 해줘야겠다

너무 많은 것들에 에너지를 쓰지 말것 , 더더욱 나에게만 몰두할 것 !!!

나를 사랑해주고 나를 아껴주는 내 소중한 사람들과 함께 이 또한 씐나게 헤쳐나갈것 ❤️

오늘도 참 감사한 하루 ❤️ 더 열심히하고 더 노력해야지, 더 좋은 사람이 되야지 ❤️❤️

'📖 나의 개발일지 (WIL&TIL)' 카테고리의 다른 글

[TIL] 오늘의 개발일지  (0) 2023.04.01
[TIL] 오늘의 개발일지  (0) 2023.03.31
[TIL] 오늘의 개발일지  (0) 2023.03.29
[TIL] 오늘의 개발일지  (0) 2023.03.28
[TIL] 오늘의 개발일지  (0) 2023.03.27

댓글