일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 의존성
- 클린코드
- interface
- 디자인패턴
- fp
- 객체지향프로그래밍
- 의도
- 협업
- 인터페이스
- CleanCode
- Solid
- 함수형프로그래밍
- 개발
- SWIFT
- iOS프로그래밍
- protocol
- 고차함수
- 함수형패러다임
- Swfit
- 클린소프트웨어
- 문법
- POP
- 네이밍
- DesignPattern
- 개발자
- 부스트코스
- 아이폰프로그래밍
- 이름
- OOP
- IOS
- Today
- Total
목록클린소프트웨어 (14)
밤에 쓴 코드
클래스 클래스는 데이터와 연산으로 이루어진 코드 블럭이다. 깨끗한 클래스, 응집도높은 클래스에 대한 고민을 해보자 클래스는 작아야한다 클래스를 만들 때 첫번째 규칙은 크기이다. 클래스는 작아야한다. 하지만 얼마나 작아야 하는지가 중요하다. 여기서 말하는 크기는 물리적인 크기보다는 책임의 크기이다. 책임을 적게 가진다는 것을 어떻게 표현할 수 있을까? 클래스의 이름은 클래스의 책임을 표현한다. 이름에 드러나는 책임이 모호하거나, 많은 책임을 내포한다면, 여러 책임을 가진 클래스일 확률이 높다. 책임을 분리하는 것은 클래스가 변경될 수 있는 이유를 분리하는 것이고, 관심사를 분리하는 것이다. 응집도 클래스에는 인스턴스 변수가 많아서는 안된다. 또 메소드는 적어도 하나이상의 인스턴스 변수를 내부에서 사용해야한..
객체와 자료구조 객체는 일을 한다 . 자료구조는 자료를 저장한다. 이 둘을 적절한 상황에 사용하기 위해 한번 공부해보자 우리는 객체를 디자인함에 있어서 , 객체의 내부의 변수를 private로 감추어둔다. 외부의 객체가 내 변수에 의존하지 않게 하기 위해서 이다. 변수의 수정에 외부에 영향을 주지 않게 하기 위해서, 외부에서는 내 변수에 대해 아무것도 모르게 하려고 더 좋은 구조를 위해서 변수의 수정에 자유로울 수 있기 위해서이다. 객체는 내부의 구현을 숨기고 *객체가 무슨 일을 하는지 * 만을 공개한다. 자료구조는 내부의 변수(자료)를 공개하고 별다른 동작을 하지 않는다 struct MyPoint { private var x: Int private var y: Int func getX() -> Int ..
제네릭 제네릭은 일종의 자리맡기 타입 (place holder) 을 이용한 구현이다 배열과 딕셔너리 같이 많은 어떤 특정 조건만 준수하면 어떤 타입이든 수용할 수 있는 구조체들이 존재한다. Generic을 한국어로 표현하면 포괄적인,일반적인 이라고 표현됨을 인지하고 프로그래밍에서의 Generic을 이해해보자 일단 제네릭표현법을 코드로 작성해보겠다. 이전에 사용자정의 연산자를 인용하여 진행한다. infix operator func (lhs: inout Int, rhs: inout Int) { let temp = lhs lhs = rhs rhs = temp } 위와 같이 서로를 바꾸는 연산자를 구현했다. var a: Int = 1 var b: Int = 2 print("a: \(a) , b: \(b)") /..
형식맞추기 코드형식은 의사소통형식이다. 가독성 수준은 유지보수 용이성과 확장성에 밀접하게 영향을 준다. 코드는 일차적으로 구현을 생각하고 , 기능이 수행되는 것에 만족해왔었다. 그 이유중 하나는 왜 깨끗하게 코드를 짜야할까? 의문을 가져본 적이 없었고, 그 이유를 몰랐었다. 왜냐면 난 학생이었고, 언제나 혼자 소프트웨어를 개발해왔었으며, 한번 완성된 소프트웨어에 기능을 수정하고, 기능을 추가하는 등, 변경되는 요구사항에 대해서 소프트웨어를 지속적으로 수정해 본 적이 없었다. 깨끗한 코드 ? 좋다는 건 알겠다. 깨끗한 코드 그게 기능구현의 중요성에 비해 노력을 투자할 가치가 많이 있는가? 를 항상 의심해왔다. 우리가 사용하는 소프트웨어는 대부분 단 한명의 개발자가 완성하지 않고, 많은 유능한 개발자들이 함..
주석 주석은 기껏해야 필요악이다. - 로버트.C.마틴 책을 읽기전까진 , 주석은 읽기 편하게 설명을 해주고 있다고 느꼈고, 꼭 필요하다고 생각했었다. 코드를 읽는 것보다 주석을 읽으면 빠르게 이해되고, 이해가 안되는 코드도 주석을 읽고 보면 술술 읽혀 나갔던 적이 많았다. 하지만 이 책에서는 주석은 코드의 실패라고 한다. 내가 주석이 유용하다고 느낀 건 주석이 유용해서가 아니라 코드가 의도를 표현하지 못하고 복잡하고 명료하게 작성되서라는 것을 알게 되었다. "주석이 필요한 코드는 잘못 작성된 코드이다" 라고 생각된다. // 이름을 가져오는 메서드 func get() -> String { return self.name } 위와 같이 주석이 메소드의 동작을 설명해주는 주석을 보는 것보다는 func getNa..
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("\(초)초") } } 초시계를 만들어 보았다. 근데 초시계의 동작을 모두 수행하면서 분까지 보고싶은 마음에 , 분초..