일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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
- c#
- MVC
- C# MDB Handle
- GDI+
- solid
- DrawEllipse
- 디자인 패턴
- 공공 데이터 포털
- Json.NET
- eventhandler
- DrawRectangle
- delegate
- Cell Border Style
- 경기도 버스
- 경기도 버스정보시스템
- WPF
- TDD
- 시
- C# MDB
- sqlite3
- JSON
- eventargs
- MDB Select
- NUnit
- 객체지향
- 버스 API
- MDB Connect
- Winform
- C# 파일 암/복호화
- Excel Cell Format
Archives
- Today
- Total
White Whale Studio
[SOLID] 단일책임원칙 / SRP : Single Responsibility Priciple 본문
IT Engineering/객체지향&디자인 패턴
[SOLID] 단일책임원칙 / SRP : Single Responsibility Priciple
glorymind 2016. 6. 24. 10:05반응형
SOLID 설계 원칙은 객체 지향 프로그래밍을 할 때 중요한 원칙들입니다.
단일 책임 원칙 : Single Responsibility Principle - SRP
개방 폐쇄 원칙 : Open-Closed Principle - OCP
리스코프 치환 원칙 : Liskov Substitution Principle - LSP
인터페이스 분리 원칙 : Interface Segregation Principle - ISP
의존역전 원칙 : Dependency Inversion Principle - DIP
위에서 보시는 바와 같이 총 5개의 원칙들의 앞 자만을 따서 SOLID라고 합니다.
각 원칙들에 대해서 찬찬히 살펴보겠습니다.
우선 해당 포스팅에서는 단일 책인 원칙에 대해서 살펴보겠습니다.
단일 책임원칙은 다음과 같습니다.
클래스는 단 1개의 책임을 가져야한다. / 클래스를 변경하는 이유는 단 1개여야 한다.
결국 말하고자 하는 것은 클래스는 단일 책임을 가지고서 다른클래스들과의 의존성을 최대한 줄인다는것이 목적입니다.
단일 책임을 지키지 않는경우
1. 한 클래스의 코드 변경으로다른 책임 코드의수정이 연쇄적으로 이어질 수 있다.
2. 책임이 분리되어 있지 않아 필요하지 않은 연계 패키지까지 참조하는경우가 발생할 수 있다. -> 재사용성이 떨어짐
단일 책임 원칙을 처음부터 잘 지키는 것은 확실히 쉽지 않을 듯합니다.
이러한 원칙을 지키기 위한 방법은 메서드를 실행하는 것이 누구인가를 확인해 볼 필요가 있습니다.
클래스의 서로 다른 사용자들이 클래스 내부에 있는 서로 다른 메서드들을 참조한다면 클래스 내부의 메서드들은 다른 책임에 속할 가능성이 높고 이러한 메서드들을 책임을 분리해야 좋은 대상이 될 수 있습니다.
반응형
'IT Engineering > 객체지향&디자인 패턴' 카테고리의 다른 글
Singleton Pattern / 싱글톤 패턴 (0) | 2016.06.24 |
---|---|
[SOLID] 개방 폐쇄 원칙 / OCP : Open Close Principle (0) | 2016.06.24 |
Facade Pattern (파사드 패턴) (0) | 2016.06.17 |
Decorator Pattern (데코레이터 패턴) (0) | 2016.06.17 |
[객체지향 개발] 캡슐화(Capsulation) (0) | 2016.06.16 |
Comments