밤에 쓴 코드

클래스 클래스는 데이터와 연산으로 이루어진 코드 블럭이다. 깨끗한 클래스, 응집도높은 클래스에 대한 고민을 해보자 클래스는 작아야한다 클래스를 만들 때 첫번째 규칙은 크기이다. 클래스는 작아야한다. 하지만 얼마나 작아야 하는지가 중요하다. 여기서 말하는 크기는 물리적인 크기보다는 책임의 크기이다. 책임을 적게 가진다는 것을 어떻게 표현할 수 있을까? 클래스의 이름은 클래스의 책임을 표현한다. 이름에 드러나는 책임이 모호하거나, 많은 책임을 내포한다면, 여러 책임을 가진 클래스일 확률이 높다. 책임을 분리하는 것은 클래스가 변경될 수 있는 이유를 분리하는 것이고, 관심사를 분리하는 것이다. 응집도 클래스에는 인스턴스 변수가 많아서는 안된다. 또 메소드는 적어도 하나이상의 인스턴스 변수를 내부에서 사용해야한..

객체와 자료구조 객체는 일을 한다 . 자료구조는 자료를 저장한다. 이 둘을 적절한 상황에 사용하기 위해 한번 공부해보자 우리는 객체를 디자인함에 있어서 , 객체의 내부의 변수를 private로 감추어둔다. 외부의 객체가 내 변수에 의존하지 않게 하기 위해서 이다. 변수의 수정에 외부에 영향을 주지 않게 하기 위해서, 외부에서는 내 변수에 대해 아무것도 모르게 하려고 더 좋은 구조를 위해서 변수의 수정에 자유로울 수 있기 위해서이다. 객체는 내부의 구현을 숨기고 *객체가 무슨 일을 하는지 * 만을 공개한다. 자료구조는 내부의 변수(자료)를 공개하고 별다른 동작을 하지 않는다 struct MyPoint { private var x: Int private var y: Int func getX() -> Int ..

Design Pattern) 데코레이터 패턴 기본샌드위치🥙를 맛있게 꾸며보자 서브웨이 샌드위치 가게에 가보자. 여러가지 기본 샌드위치 메뉴가 있는데 특별한 토핑을 추가할 수 있고, 사용자가 원하는 대로 더할 수 있거나 뺄 수 있다. 또 추가금액을 내고 토핑을 추가하는 경우도 있다. 토핑의 종류가 하나씩 추가됨에 따라서 ,우리가 만들 수 있는 샌드위치는 더더욱 다양해진다. 어떻게 하면 계속적으로 늘어나는 메뉴를 감당할 수 있을까? 아보카도 🥑 에그오믈렛 🍳 베이컨 🥓 더블치즈 🧀 X X X X X X X O X X O X X X O O X O X X X O X O X O O X X O X O O X X X O X X O O X O X O X O O O O X X O O X O O O O X O O O O ..

객체의 지도 객체를 설계함에 있어서 어떤 고민을 해볼 지 생각해 보자 기능과 구조 지금 부엉이가 친구 병아리를 만나려고 한다. 그래서 병아리는 부엉이에게 자신의 위치를 알려준다. ➡️ 으로 2블럭 ⬆️ 으로 2블럭 이렇게 위치를 설명해 주었다. 이렇게 집을 찾을 수 있었다. 그런데 만약 부엉이가 시작점이 변경된다면? 과연 위에 길안내는 유효할 것인가? ➡️ 으로 1블럭 ⬆️ 으로 2블럭 으로 길 안내가 변경 되었다. 부엉이(사용자)가 위치설명(목표)를 위해 요청 했을 때, 부엉이의 위치(사용자의 상황-요구사항) 에 따라서 절차(기능)들이 변경되었다. 이처럼 특정 요구사항 마다 , 기능들이 변경되었다, 하지만 구조적으로 접근을 했다면, 다른 결과를 얻을 수 있다. 부엉이에게 이런 지도(구조)를 손에 쥐어 ..

ISP- 인터페이스 분리 법칙 (Interface segregation principle) 클래스 내에서 사용하지 않는 인터페이스는 구현하지 말아야 한다. DIP 에서 만들어진 고양이가 잘 이동하고 있다 . DIP - 의존관계 역전법칙(Dependency inversion Principle) 강아지도 추가해서 , 이쁘게 움직이게 만들어 주었다. 그런데 어느날 '달팽이'가 필요해졌다. struct 달팽이(){ let 움직이기전략: 움직이는방법 // 구체적이지 않은 클래스에 의존 func 이동하기(){ 움직이기전략.이동하다() } //DI - 의존성주입 mutating func 움직이는방법바꾸기(_ 새로운움직이기전략:움직이는방법){ self.움직이기전략 = 새로운움직이기전략 } }struct ..

DIP - 의존관계 역전법칙(Dependency inversion Principle) 추상화 된 것은 구체적인 것에 의존하면 안되고 구체적인 것이 추상화된 것에 의존해야 한다 위에서는 변할수 있는것 과 변하지 않을 것 을 나누는 게 중요했다. 그리고 구체적일 수록 잘 변했고 , 구제적이지 않을 수록 잘 변하지 않았다. 객체사이의 서로 도움을 주고 받으면서 협력을 하게 되면 어쩔수 없이 의존관계가 생길 수밖에 없다. struct 평범한움직임{ func 이동하다() { print("🐾") } func 점프하다() { print("💨") } } struct 고양이 { let 움직이는전략: 평범한움직임 // 구체 클래스 func 이동하기(){ 움직이는전략.이동하다() } func 점프하기(){ 움직이는전략.점프..

LSP - 리스코프 치환 원칙 (Liskov substitution principle) 자식클래스 (서브클래스) 는 부모클래스(슈퍼클래스)의 역할을 완벽히 수행할 수 있어야한다. 호오 당연한 얘기 아닌가? '새'를 상속받은 '부엉이는 '새'로써의 역할을 완벽히 해야한다. 맞는 말인데 이게 좀 처럼 지켜지지 않는다. 이 문제는 서브클래스가 슈퍼클래스의 메소드를 Override 하는 과정에서 발생한다. class 초시계 { var 초:Int = 0 func 시간이흐르다(){ 초 = 초 == 59 ? 0 : 초 + 1 } func 시간보여주기(){ print("\(초)초") } } 초시계를 만들어 보았다. 근데 초시계의 동작을 모두 수행하면서 분까지 보고싶은 마음에 , 분초..

OCP -개방폐쇄 원칙 (Open-closed principle) 확장에 개방적이고 , 변경에 폐쇄적이어야한다. 음? 처음에 확장과 변경이 그렇게 다른 것인지 의문을 가졌었다. 일단 확장은 기능의 추가이고 , 변경은 기능구현의 변경이다. 기능을 추가할때는 딱 기능만 추가할 수 있게 , 즉 기존의 다른 부분들에 수정이 필요 없게 , 기능이 변경이 , 이 기능을 가져다 쓰는 다른 코드들에 영향을 주지않게 해야한다는 것이다. 개발을 접하지 않은 사람들이 보기에 어찌보면 당연하게 들릴 것이다. 기능을 추가하면 기능만 추가 되면 그만이지. 변경되면 변경만 되면 그만이지 라고 생각 할 수 있다 . 이 과정은 생각보다 쉽지 않다 . 하지만 우리는 저 어렵지만 당연한 생각 을 실천해야한다. 변경에 폐쇄적이려면 어떻게 ..