«solid» 태그된 질문

설계 원칙 세트에 대한 니모닉 : 단일 책임, 개방 폐쇄, Liskov 대체, 인터페이스 분리, 종속성 반전

5
인터페이스 (OOP)의 시맨틱 계약이 기능 서명 (FP)보다 유익한 정보입니까?
일부는 SOLID 원칙을 최대한 활용하면 기능적 프로그래밍을하게 된다고 말합니다 . 나는이 기사에 동의하지만 인터페이스 / 객체에서 함수 / 클로저로의 전환에서 일부 의미가 손실된다고 생각하며 함수 프로그래밍이 손실을 완화시키는 방법을 알고 싶습니다. 기사에서 : 또한 ISP (Interface Segregation Principle)를 엄격하게 적용하면 헤더 인터페이스보다 역할 인터페이스를 선호해야합니다. 더 작고 더 작은 인터페이스를 …
5
C에서 인터페이스 분리 원리를 적용하는 방법?
'C', 'C2', 'C3'과 같은 클라이언트가있는 'M'이라는 모듈이 있습니다. 모듈 M의 네임 스페이스, 즉 API 및 노출 된 데이터 선언을 헤더 파일에 할당하여 다음과 같은 방식으로 헤더 파일에 할당하고 싶습니다. 모든 클라이언트의 경우 필요한 데이터 및 API 만 표시됩니다. 모듈의 나머지 네임 스페이스는 클라이언트에서 숨겨집니다. 즉, 인터페이스 분리 원칙을 준수하십시오 . …
15 c  interfaces  solid 
4
테스트 중심 개발로 인해 SOLID를 따라야합니까?
TDD 실무자 로부터 TDD 의 장점 중 하나는 개발자가 SOLID 원칙 (단일 책임, 개방 폐쇄, Liskov 대체, 인터페이스 분리 및 종속성 반전) 을 따르도록 강요한다는 것 입니다. 그러나 저에게는 SOLID를 따르는 것이 중요하므로 테스트 가능한 아키텍처를 만드는 것이 중요하다는 것을 이해하기 위해 몇 가지 테스트 (주로 단위 테스트)를 작성하는 것으로 …
3
RxJava 클래스 Flowable이 합법적으로 460 개의 메소드를 가질 수 있습니까?
Java의 ReactiveX 구현 인 RxJava ( Rx 및 Reactive Extensions 라고도 함)를 막 시작했습니다 . 실제로 나를 놀라게 한 것은 RxJava의 Flowable 클래스 의 거대한 크기였습니다 . 460 개의 메소드가 있습니다! 공정하게 : 오버로드 된 메소드가 많으므로 총 메소드 수에 상당한 영향을 미칩니다. 아마도이 클래스는 분리되어야하지만 RxJava에 대한 나의 지식과 …
2
실제 세계-Liskov 대체 원리
배경 : 메시징 프레임 워크를 개발 중입니다. 이 프레임 워크는 다음을 허용합니다. 서비스 버스를 통한 메시지 전송 메시지 버스의 대기열에 가입 메시지 버스의 주제 구독 현재 RabbitMQ를 사용하고 있지만 가까운 시일 내에 Microsoft Service Bus (Premise)로 전환 할 것입니다. ServiceBus로 이동할 때 클라이언트 코드 (예 : 게시자 또는 구독자)를 수정하지 …
4
수업에 대한 단일 책임 패턴은 얼마나 구체적이어야합니까?
예를 들어, 콘솔 게임 프로그램에 콘솔에 대한 모든 종류의 입력 / 출력 방법이 있다고 가정하십시오. 하나에 모두 유지하는 스마트겠습니까 inputOutput클래스 또는 같은보다 구체적인 클래스로 분해 startMenuIO, inGameIO, playerIO, gameBoardIO, 각 클래스 1-5 방법에 대해이 등 있도록? 같은 메모에서 그것들을 분류하는 것이 낫다면 IO네임 스페이스 에 배치하는 것이 현명 할 것입니다 …
3
실제로 열린 원칙을 고수하는 방법
공개 원칙의 의도를 이해합니다. 수정하지 않고 확장하도록 지시함으로써 수정하는 동안 이미 작동하는 것을 깨뜨릴 위험을 줄입니다. 그러나이 원칙이 실제로 어떻게 적용되는지 이해하는 데 어려움이있었습니다. 내 이해에는 두 가지 방법이 있습니다. 변경 전과 후에 : 이전 : 추상화에 프로그래밍하고 가능한 한 '미래를 예측'하십시오. 예를 들어, 향후 시스템에 s가 추가 drive(Car car)되면 …
3
인터페이스 분리 원리에 대한 두 가지 모순 된 정의 – 어느 것이 맞습니까?
ISP에서 기사를 읽을 때 ISP에 대해 두 가지 상반되는 정의가있는 것 같습니다. 첫 번째 정의에 따르면 ( 1 , 2 , 3 참조) ISP는 인터페이스를 구현하는 클래스가 필요하지 않은 기능을 구현하도록 강요해서는 안된다고 말합니다. 따라서 뚱뚱한 인터페이스IFat interface IFat { void A(); void B(); void C(); void D(); } class …
1
상속 계층에서 Liskov 대체 원칙을 확인하는 방법은 무엇입니까?
이 답변에서 영감을 얻었습니다 . 리스 코프 치환 원칙은 필요 있음 하위 유형에서는 전제 조건을 강화할 수 없습니다. 하위 유형에서는 사후 조건을 약화시킬 수 없습니다. 상위 유형의 변형은 하위 유형으로 유지되어야합니다. 히스토리 제한 사항 ( "히스토리 규칙"). 객체는 그 방법 (캡슐화)을 통해서만 수정 가능한 것으로 간주됩니다. 서브 타입은 수퍼 타입에 …
2
LinkedList를 확장하는 스택. Liskov 대체 원칙 위반?
add_first (), add_last (), add_after (), remove_first (), remove_last () 및 remove ()와 같은 함수가있는 LinkedList 클래스가 있습니다. 이제 push (), pop (), peek () 또는 top ()과 같은 기능을 제공하는 클래스 스택이 있으며 이러한 메소드를 구현하기 위해 LinkedList 클래스 메소드를 확장합니다. 이것이 Liskov 대체 원칙을 위반합니까? 예를 들어, 링크 …
4
모의가 개방 / 폐쇄 원칙을 위반합니까?
얼마 전에 나는 찾을 수없는 스택 오버플로 답변에서 공개 API를 테스트해야한다고 설명하는 문장을 읽었으며 저자는 인터페이스를 테스트해야한다고 말했습니다. 저자는 또한 메소드 구현이 변경되면 테스트 케이스를 수정할 필요가 없다고 설명했다. 이렇게하면 테스트중인 시스템이 작동하는 계약을 깨뜨릴 수 있기 때문이다. 즉, 메소드가 작동하지 않으면 테스트가 실패하지만 구현이 변경 되었기 때문에 실패해야합니다. 우리가 …
3
Dependency Inversion Principle : 다른 사람에게“높은 수준의 정책”과“낮은 수준의 세부 사항”을 정의하는 방법은 무엇입니까?
나는 (주로 후배) 동료들에게 의존성 역전 원리를 설명하려고합니다. 소프트웨어에서 어떤 정책이 "고수준 정책"이고 어떤 정책이 "저수준 세부 사항"인지 어떻게 정의 할 수 있습니까? 예를 들어 소프트웨어가 여러 비즈니스 응용 프로그램의 워크 플로를 자동화하는 경우 워크 플로 자동화가 고급 정책이고 비즈니스 응용 프로그램이 세부 정보라고 말하는 이유는 무엇입니까?
1
타사 코드를 포장하여 소비자를 단위 테스트하는 유일한 솔루션입니까?
단위 테스트를 수행하고 있으며 클래스 중 하나에서 메소드 중 하나에서 메일을 보내야하므로 생성자 주입을 사용하여 Zend_MailZend 프레임 워크 에있는 클래스 인스턴스를 주입합니다 . 이제 일부 사람들은 라이브러리가 충분히 안정적이며 자주 변경되지 않으면 랩핑 할 필요가 없다고 주장합니다. 따라서 그것이 Zend_Mail안정적이며 변경되지 않고 내 요구에 완전히 부합 한다고 가정하면 래퍼가 필요하지 …
3
SOLID 원리 적용
저는 SOLID 설계 원칙에 익숙하지 않습니다 . 나는 그들의 원인과 이점을 이해하지만 SOLID 원칙을 사용하기위한 실제 연습으로 리팩토링하려는 더 작은 프로젝트에는 적용하지 않습니다. 완벽하게 작동하는 응용 프로그램을 변경할 필요는 없지만 어쨌든 리팩터링하여 향후 프로젝트의 디자인 경험을 얻고 싶습니다. 응용 프로그램에는 다음과 같은 작업이 있습니다 (실제로는 그 이상이지만 간단하게 유지하십시오). 데이터베이스 …
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.