3주차 정리

단일 책임 원칙

단일 책임 원칙(SRP)이란 클래스와 모듈은 하나의 책임 또는 기능만을 가지고 있어야 한다는 설계 원칙

단일 책임 원칙이 설명하는 대상에는 클래스와 모듈이라는 두 가지 종류가 있다.

1. 모듈을 클래스보다 더 추상적인 개념으로 간주하고 클래스를 일종의 모듈로 간주하는 것
2. 모듈을 좀 더 포괄적인 범위의 대상으로 놓고, 여러 클래스가 하나의 모듈을 구성한다고 간주하는 것

단일 책임 여부를 결정하기 위해 사용되는 몇 가지 결정 원칙

1. 클래스에 코드, 함수 또는 속성이 너무 많아 코드의 가독성과 유지 보수성에 영향을 미치는 경우 클래스 분할을 고려해야 한다.
2. 클래스가 너무 과하게 다른 클래스에 의존한다면, 높은 응집도와 낮은 결합도의 코드 설계 사상에 부합하지 않으므로 클래스 분할을 고려해야 한다.
3. 클래스에 private 메서드가 너무 많은 경우 이 private 메서드를 새로운 클래스로 분리하고 더 많은 클래스에서 사용할 수 있도록 public 메서드로 설정하여 코드의 재사용성을 향상 시켜야 한다.
4. 클래스의 이름을 비즈니스적으로 정확하게 지정하기 어렵거나 Manager, Context 처럼 일반적인 단어가 아니면 클래스의 이름을 정의하기 어려울 경우, 클래스 책임 정의가 충분히 명확하지 않음을 의미할 수 있다.
5. 클래스의 많은 메서드가 여러 속성 중 일부에서만 작동하는 경우 이러한 속성과 해당 메서드를 분할하는 것을 고려할 수 있다.

그치만 항상 클래스를 최대한 작게 나누는 것이 좋은 것은 아니다.

개방 폐쇄 원칙

모듈, 클래스, 함수와 같은 소프트웨어의 단위들은 확장을 위해 개방되어야 하지만 수정을 위해서는 폐쇄되어야 한다. 새로운 기능을 추가할 때 기존의 모듈, 클래스, 함수를 수정하기보다는 기존 코드를 기반으로 모듈, 클래스, 함수 등을 추가하는 방식으로 코드를 확장해야 한다는 뜻이다.

개방 폐쇄 원칙 기반의 높은 확장성을 지원하는 코드를 작성하는 방법의 핵심은 확장 포인트를 미리 준비해두는 것이 좋다.

리스코프 치환 원칙

하위 유형 또는 파생 클래스의 객체는 프로그램 내에서 상위 클래스가 나타나는 모든 상황에서 대체 가능하며, 프로그램이 원래 가지는 논리적인 동작이 변경되지 않으며 정확성도 유지된다.

위반하는 안티패턴

1. 하위 클래스가 구현하려는 상위 클래스에서 선언한 기능을 위반하는 경우
2. 하위 클래스가 입력, 출력 및 예외에 대한 상위 클래스의 계약을 위반하는 경우
3. 하위 클래스가 상위 클래스의 주석에 나열된 특별 지침을 위반하는 경우

인터페이스 분리 원칙

클라이언트는 필요하지 않은 인터페이스를 사용하도록 강요되어서는 안 된다.

(클라이언트는 인터페이스 호출자나 사용자로 이해)

인터페이스 분리 원칙에서 이야기하는 인터페이스는 크게 다음 세 가지 중 하나를 의미한다.

• API나 기능의 집합
• 단일 API 또는 기능
• 객체지향 프로그래밍의 인터페이스

생각해보기

단일 책임 원칙과 분리 원칙은 준수하는 듯 하고, 검색하자마자 이 둘의 성능상의 차이가 있는지에 대한 글이 있는데, 동작도 비슷하고 이걸 굳이 나눠놓은 이유?를 묻는 글인 것 같았다.

https://stackoverflow.com/questions/15137308/atomicinteger-incrementandget-vs-atomicinteger-getandincrement

결론

둘은 성능상의 차이는 없는 듯하다. 진짜로 더하기 전에 가져오는 것과 더하고 나서 가져오는 것의 차이일 뿐!

의존 역전 원칙

• 제어 반전

제어 반전은 특정한 기술이 아니라 일반적으로 프레임워크를 사용할 때 만나게 되는 보편적 설계 사상에 가까움

• 의존성 주입

new 예약어를 사용하여 클래스 내부에 종속되는 클래스의 객체를 생성하는 대신, 외부에서 종속 클래스의 객체를 생성한 후 생성자, 함수의 매개변수 등을 통해 클래스에 주입하는 것을 의미

• 의존 역전 원칙

의존 역전 원칙의 정의는 상위 모듈은 하위 모듈에 의존하지 않아야 하며, 추상화에 의존해야만 한다. 또한 추상화가 세부 사항에 의존하는 것이 아니라, 세부 사항이 추상화에 의존해야 함

상위 모듈과 하위 모듈은 어떻게 구분하는가?

간단히 말해서 호출자는 상위 모듈에 속하고, 수신자는 하위 모듈에 속한다. 의존 역전 원칙은 제어 반전과 유사하게 프레임워크의 설계를 사용하도록 하는 데 주로 사용된다.

KISS 원칙

KISS 원칙이란 디자인에서 간단하고 알기 쉽게 만드는 편이 좋다는 원리

또, 사실 복잡하다고 반드시 KISS 원칙을 위반하는 것은 아님! 응용 시나리오에 따라 항상 다른 법!

KISS 원칙을 만족하는 코드 작성 방법

• 복잡한 정규표현식, 프로그래밍 언어에서 제공하는 지나치게 높은 레벨의 코드 등 지나치게 복잡한 기술을 사용하여 코드를 구현하지 않는다.
• ‘바퀴를 다시 발명’하는 대신 기존 라이브러리를 사용하는 것을 고려한다. 라이브러리의 기능을 직접 구현하면 버그가 발생할 확률이 높아지고 유지 관리 비용도 덩달아 높아진다.
• 과도하게 최적화하지 않는다. 코드를 최적화하기 위해 산술 연산 대신 비트 연산을 사용하거나 if-else 대신 복잡한 조건문을 사용하는 것을 최소화한다.

YAGNI 원칙

YAGNI 원칙을 소프트웨어 개발에 적용하면, 현재 사용되지 않는 기능을 설계하지 말고 현재 사용되지 않는 코드를 작성하지 않는다는 의미. 즉, 과도하게 설계하지 말라는 것!

KISS 원칙은 가능한 한 간단하게 유지하라는 방법에 관한 것이지만, YAGNI 원칙은 현재 필요하지 않은 것을 미리 하지 말라는 금지에 관한 것이다.

DRY 원칙

DRY 원칙은 흔히 중복 코드를 작성하지 말라는 뜻으로 번역된다. 코드 논리의 중복에 대한 중복보다는 의미론적인 중복에 대한 중복이 더 크다는 느낌을 받았다. 회사의 레거시한 코드에서도 누군가가 구현해 놓은 코드를 없다고 판단하여, 다시 구현된 코드를 없다고 판단하여 다시 구현하는 경우도 자주 봐왔기 때문에 중요한 듯 싶다.

3의 법칙이란 무엇인가,,,??!!

https://gettingresults.com/explained-the-rule-of-3/

3의 법칙이 왜 그렇게 효과적인가?

3의 법칙은 강력한 의사소통 원칙이며, 사물을 조각조각 나누는 강력한 방법입니다.

3의 법칙의 기본 아이디어는 3개로 표현된 아이디어가 더 매력적이고, 기억하기 쉽고, 효과적이라는 것입니다.

1. 분명한 것은 정보를 세 개로 그룹화하면 처리하고 기억하기가 더 쉽다는 것입니다.
2. 통찰력이 뛰어납니다. 이 패턴은 인간이 만족스럽고 매력적으로 느끼는 자연스러운 리듬을 활용합니다.
3. 실행 가능합니다. 프레젠테이션, 연설 또는 글쓰기에서 사용하여 요점을 공감하게 만드세요. 예를 들어, 세 가지 핵심 요점으로 주장을 구성하고, 세 가지 예를 사용하여 아이디어를 설명하거나, 명확성과 영향을 위해 세 섹션으로 콘텐츠를 구성하세요.

이 규칙은 단순성과 리듬을 활용해 의사소통 효과를 높입니다.

 

유명한 법칙이라길래 뭔가 했는데, 코드를 작성할 때 세가지를 고려하라는 말로 해석을 해야 하는 걸까..?? 처음 코드를 작성할 때 재사용성을 고려하지 않고, 나중에 재사용 시나리오를 만나면 다시 사용할 수 있도록 리팩터링하면 된다. 재사용성 + 시나리오 + 리팩터링 이 세가지만 고려하면 DRY 원칙을 해결할 수 있다는 말인걸까?

LoD

데메테르의 법칙(LoD)은 모듈이나 클래스가 상호작용하는 객체의 내부 구조를 알면 안 된다는 소프트웨어 설계 원칙!! 이 설계 원칙은 코드에서 높은 응집도와 낮은 결합도를 달성하는 데 도움이 될 수 있다.

1. 직접 의존성이 없어야 하는 클래스 사이에는 반드시 의존성이 없어야 한다.
2. 의존성이 있는 클래스는 필요한 인터페이스에만 의존해야 한다.