SOLID 원리 프로그래밍

시간이 지남에 따라 SOLID의 두 부분 인 “S”와“O”를 이해할 수있었습니다 .

“O”– 상속 및 전략 패턴을 통해 공개 폐쇄 원칙을 배웠습니다.

“S”– ORM을 배우면서 단일 책임 원칙을 배웠습니다 (지속성 논리는 도메인 개체에서 제외됨).

비슷한 방식으로 SOLID의 다른 부분 ( "L", "I"및 "D")을 배우는 가장 좋은 영역 / 작업은 무엇입니까?

참고 문헌

object-oriented solid

— LCJ
소스

이 모든 아이디어는 좋은 아이디어이며 함께 사용하면 매우 좋습니다. 그러나 독단적으로 적용하면 성공보다 더 많은 실패를 야기 할 수 있습니다.

OR 매퍼는 단일 책임 원칙이 아니라 우려를 분리하는 데 유용합니다. 차이점에 대한 논의는 이 게시물 programmers.stackexchange.com/questions/155628/… 을 참조하십시오 .

— Doc Brown

실제 사례 블로그 .gauffin.org

— LCJ

@JarrodRoberson Yep, 그래서 그들은 신중하게 지침서 라고 불립니다 . 또한 나머지 원칙을 잊지 마십시오 : adamjamesnaylor.com/2012/11/12/… (총 11 개)

— Adam Naylor

@AdamNaylor의 링크는 404ing이며, adamjamesnaylor.com/post/로 이동되었습니다 .

— mattumotu

답변:

매우 유용한 기사를 찾을 때까지 몇 달 전에 신발에있었습니다.

각 원칙은 각 소프트웨어 개발자가 프로젝트에서 직면 할 수있는 실제 상황으로 잘 설명되어 있습니다. 나는 여기서 짧게 자르고 참조 -SOLID Software Development, 한 번에 한 단계 씩을 가리키고 있습니다.

의견에서 지적했듯이, 또 다른 아주 좋은 PDF 읽기 -Pablo 's SOLID Software Development가 있습니다.

또한 SOLID 원칙에 대해 자세히 설명하는 좋은 책이 있습니다. SOLID 소프트웨어 개발에 관한 좋은 책 .

각 원칙에 대한 간단한 요약 편집 및 의견 :

“S”– 단일 책임 원칙은 변화를 허용하는 비즈니스 요구에 따라 결정됩니다. “변경해야 할 단일 이유”는 기술 개념이 아닌 비즈니스 개념과 컨텍스트를 고려하여 논리적으로 분리 된 개념을 그룹화해야한다는 것을 이해하는 데 도움이됩니다. In another words, 나는 각 수업마다 하나의 책임이 있어야한다는 것을 배웠다 . 책임은 지정된 작업을 수행하는 것입니다.
“O”– Open Closed Principle을 배우고 "상속보다 컴포지션 선호"를 시작했습니다. 따라서 가상 메서드가없고 봉인되어 있지만 확장을위한 추상화에 의존하는 클래스를 선호합니다.
“L”– 데이터 액세스 관리를위한 리포지토리 패턴의 도움으로 Liskov 대체 원칙을 배웠습니다.
“I”– ASP.NET 2.0의 멤버 자격 공급자와 같이 클라이언트가 사용하지 않는 인터페이스를 강제로 구현해서는 안된다는 사실을 알게되어 인터페이스 분리 원리에 대해 배웠습니다. 따라서 인터페이스에는 "많은 책임"이 없어야합니다
“D”– Dependency Inversion Principle에 대해 배우고 변경하기 쉬운 코딩을 시작했습니다 . 변경이 쉬워지면 총 소유 비용이 절감되고 유지 보수성이 향상됩니다.

CodePlex의 유용한 리소스가 주석에 언급되었으므로 SOLID에 대한 참조가 예제로 포함되어 있습니다.

— 엘 유수 보프
소스

다음 기사들이 매우 유용하다는 것을 알았습니다 : lostechies.com/wp-content/uploads/2011/03/…

— Scroog1

나는 전체 기사를 읽었으며 패턴이나 SOLID에서 판매되지 않았습니다. 예제는 너무 단순하지만 복잡해지면 복잡성이 인공적입니다. 더 나은 대안없이 실제 SOLID OOP를 만나지 못했습니다.

— Job

lostechies 기사가 여기에 언급 되었으므로이 solidexamples.codeplex.com도 있습니다 ( lostechies 기반)

— dark fader

저는 Pablos eBook의 기고자 중 한 사람이었습니다. 사람들이 여전히 유용하다고 생각합니다. :)

— Sean Chambers

공개 폐쇄 원칙을 요약 할 수 있다면 +1000000입니다. 모두가이 점을 잘못 알고 상속에 대해 생각합니다

— AlexFoxGill

(1) 표면 분리 및 (D) 종속성 반전은 단위 테스트 및 조롱을 통해 학습 할 수 있습니다. 클래스가 자신의 의존성을 만들면 좋은 단위 테스트를 만들 수 없습니다. 그것들이 너무 넓은 인터페이스 (또는 전혀 인터페이스가 아님)에 의존한다면, 유닛 테스트를 위해 조롱해야 할 것이 무엇인지는 분명하지 않습니다.

— StriplingWarrior
소스

+1 이것은 매우 사실입니다. 때로는 너무 엄격한 'imo'를 준수 할 필요가 없습니다. '단일 테스트 만 한 가지만 테스트해야합니다'규칙 : 몇 분 동안 수업에 적합한 테스트 스위트를 만들 수 없다면 I와 D 그리고 아마도 다른 알파벳도 위반합니다

— stijn

Liskov 대체 원칙은 기본적으로 구현 상속을 과도하게 사용하도록 허용하지 않습니다. 코드 재사용을 위해서만 상속을 사용해서는 안됩니다 (구성이 있음)! LSP를 준수함으로써 실제로 수퍼 클래스와 서브 클래스 사이에 "is-a relation"이 존재한다는 것을 확신 할 수 있습니다.

말하는 것은 서브 클래스가 서브 클래스의 메소드 구현과 유사한 방식으로 서브 클래스의 모든 메소드를 구현해야한다는 것입니다. 수퍼 타입이 예외를 던질 때 NOP를 구현하여 메소드를 대체하거나 널을 리턴해서는 안됩니다. 계약에 의한 설계 조건에 명시된대로, 메소드를 대체 할 때 수퍼 클래스의 메소드 계약을 존중해야합니다. 이 원칙을 위반하지 않도록 방어하는 방법은 구현 된 방법을 재정의하지 않는 것입니다. 대신 인터페이스를 추출하고 두 클래스에서 해당 인터페이스를 구현하십시오.

GRASP의 인터페이스 분리 원칙 , 단일 책임 원칙 및 고 응집 원리는 어떻게 든 관련이 있습니다. 그들은 변화에 대한 이유가 단 하나이므로 변화가 매우 쉽게 이루어 지도록 엔티티가 한 가지만 책임 져야한다는 사실을 언급한다.

실제로 클래스가 인터페이스를 구현하면 해당 인터페이스의 모든 메소드를 구현하고 사용해야한다고 말합니다. 해당 특정 클래스에 필요하지 않은 메소드가있는 경우 인터페이스가 좋지 않으며 원래 클래스에 필요한 메소드 만있는 두 개의 인터페이스로 분할되어야합니다. POV에서 고려할 수 있는데, 이전 인터페이스와 관련하여 이전 인터페이스와 관련하여 대형 인터페이스를 만들 수 없으므로 구현시 LSP가 중단 될 수 있습니다.

팩토리 패턴에서 종속성 반전 을 볼 수 있습니다 . 여기서 상위 레벨 컴포넌트 (클라이언트) 및 하위 레벨 컴포넌트 (생성 될 개별 인스턴스) 는 모두 추상화에 따라 다릅니다.(인터페이스). 계층화 된 아키텍처에 적용하는 방법 : 구현 된 계층이 아니라 호출 된 모듈의 계층에 대한 인터페이스를 정의해야합니다. 예를 들어, 데이터 소스 계층에 대한 API는 데이터 소스 계층이 아니라 비즈니스 로직 계층에서 작성해야합니다. 이러한 방식으로, 데이터 소스 계층은 비즈니스 로직에 정의 된 동작 (따라서 반전)을 상속 / 의존하고 그 반대는 아닙니다 (정상적인 방식으로). 이는 설계에 유연성을 제공하여 완전히 다른 데이터 소스를 사용하여 코드를 변경하지 않고도 비즈니스 로직을 작동시킬 수 있습니다.

— m3th0dman
소스

Liskov에 대한 훌륭한 설명. :)

— John Korsnes