Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- 의존성
- DesignPattern
- POP
- 클린소프트웨어
- 부스트코스
- SWIFT
- 네이밍
- 디자인패턴
- 아이폰프로그래밍
- 문법
- 클린코드
- OOP
- Solid
- protocol
- 협업
- interface
- 이름
- fp
- IOS
- Swfit
- 객체지향프로그래밍
- CleanCode
- 함수형패러다임
- 의도
- iOS프로그래밍
- 고차함수
- 개발
- 함수형프로그래밍
- 개발자
- 인터페이스
Archives
- Today
- Total
밤에 쓴 코드
OOP ) SOLID - 객체지향 5원칙 본문
SOLID - 객체 지향 5 원칙
나쁜설계는 변경에 취약한 소프트웨어를 만든다
나쁜소프트웨어는 디른 곳에 영향을 주어서 A기능 수정이 B기능까지 영향을 주어 , 갑자기 엉뚱한 곳이 망가질 수있고 ,
그에 따른 연쇄되는 수정이 동반되어야 할것이다.
또 서로 연관 없는 코드들이 결합되어 있기 떄문에 , 하나를 재사용하려고 해도 , 그에 관련된 코드들을 줄줄이 사용하지 않으면 시스템에 문제가 생길 것이다.
또 한 곳에서 동작이 이리저리 퍼지고 , 또 한곳에서 여러동작을 하게 되면 메소드의 이름도 모호해지고 , 하는 일도 명확해지지 않게 될 것이다.
이런 코드를 스파게티 코드 라고 부른다 .
이리저리 서로 얽히고 설켜서 , 끔찍한 코드를 보게 될 것이다 .
이 문제를 해결하기위한 많은 무기들이 있다 .
인터페이스,다형성이라는 무기로 이 문제를 해결할 수 있을것 이다.
대부분은 의존관계 때문이야
이런 문제의 대부분은 의존 관계의 때문이다.
관계없는 코드들이 서로 의존하게되면 결합도가 증가하게 된다. 또 , 쓸데없는 코드가 서로 관련된 코드에 껴 들어가게 되는 과정에서 응집도 는 낮아질 수 밖에 없다.
좋은 코드는 응집도가 높고 , 결합도가 낮다
나 자신을 라이브러리 배포자로 생각해보면 , 내가 만든 라이브러리를 배포하고 , 그걸 다른 사용자가 사용할 것이다.
내 라이브러리에 추가를 할 수도 있고, 기존코드의 변경이 있을 수 있다.
그 과정에서 기존의 라이브러리로 작성했던 다른 사용자들의 코드들이 부서질 수도 있다.
이 문제를 최소화 하기 위해서 SOLID 원칙을 지키려는 노력을 하다보면 , 조금 더 이후의 변경에 대해 안전한 라이브러리를 배포 할 수 있을 것이다 .
배포자의 입장으로 , 이걸 사용하는 사용자들의 불편함을 덜어주기위한 코드를 작성한다고 생각하면서 임해보자.
SOLID 원칙 바로가기
SRP - 단일 책임 원칙 (Single responsibility principle)
OCP -개방폐쇄 원칙(Open-closed principle)
LSP - 리스코프 치환 원칙 (Liskov substitution principle)
DIP - 의존관계 역전법칙(Dependency inversion Principle)
ISP- 인터페이스 분리 법칙 (Interface segregation principle)
'OOP' 카테고리의 다른 글
OOP ) OCP -개방폐쇄 원칙(Open-closed principle) (1) | 2019.05.18 |
---|---|
OOP ) SRP - 단일 책임 원칙 (Single responsibility principle) (0) | 2019.05.18 |
OOP ) 타입, 추상화 (0) | 2019.04.28 |
OOP ) 상태 , 행동 , 식별자 (0) | 2019.04.26 |
OOP) 역할 , 책임 , 협력 (0) | 2019.04.22 |
Comments