재사용 성이 좋은 디자인과 대략 같은 의미입니까?

재사용 성은 좋은 소프트웨어 디자인 의 특징입니다 .

재사용 성이 우수한 소프트웨어 설계에 적합한 광택 ( "의미의 의미 표기")입니까? 왜?

아니.

재사용 은 좋은 디자인 의 지표 입니다. 이는 시스템 의 커플 링 이 느슨 하고 특정 장치 의 응집력 이 높기 때문에 종속성 문제가 발생하지 않거나 대부분의 코드를 다시 작성하지 않고도 재사용이 용이함 을 나타냅니다 .

재사용 성은 대체로 환상입니다. 장치의 사용 장소 또는 방법을 미리 알지 못하면 장치의 "재사용 가능성"을 측정하는 것은 사실상 불가능합니다. 많은 개발자들은 "재사용 가능한"구성 요소를 설계 하려고 시도 하고 나중에 "유연한"구성을 시도한 특정 측면이 꼭 필요 하지 않은 부분이라는 것을 종종 알게됩니다 .

나는 다른 "광택": 테스트 가능성을 사용합니다.

이제 저는 TDD의 옹호자가 아니며, 무엇이든 모든 것을 단위 테스트 할 필요가 없다고 생각합니다. 그러나 구성 요소에 대한 테스트를 작성하면 결합 / 응집 특성에 대한 아주 좋은 아이디어를 얻을 수 있습니다. 그것이 추상화에 의존한다면, 그것은 느슨한 결합입니다. 종속성을 모의하기가 쉽고 좋은 디자인을 제안합니다. 그것은 명확한 목적이있는 경우 (또한 참조 단일 책임 원칙은 당신이 알아낼 쉽게 그것을 발견 할 것이다, 다음의 행동이 상대적으로 직관적 인 것) 무엇을 다시, 좋은 디자인을 제안 시험에.

물론 좋은 디자인을 보장 하지는 않습니다 . 실제 구현 또는 전체 아키텍처는 명시된 목적에 완전히 부적합 할 수 있습니다. 그러나 적어도 그것은 스파게티 코드 또는 신 개체로 작업하고 있지 않다는 것을 알려줍니다.

구성 요소의 "재사용 성"에 대해 특히 추측하지 말고 특히 "좋은 디자인"의 증거로 사용하지 마십시오. 실제로 재사용이 가능 해지면 디자인이 크게 변경되었을 수 있습니다.

아니.

재사용 가능성은 향후 개발 속도를 높일 수 있기 때문에 좋은 기능입니다. (실제로 거의 모든 조직이 원하는만큼의 속도로 미래 개발 속도를보고있는 조직은 거의 없습니다.) 그러나 중요한 소프트웨어에는 해당 응용 프로그램과 관련된 부분이 있습니다. 또한 도메인 경험이없는 사람들이 재사용 가능한 소프트웨어를 작성하려고 할 때, 일반적으로 실제로 재사용 할 수 없게함으로써 해당 부분을 난독 처리하고 성능을 저하시킵니다.

따라서 우수한 디자인은 모듈 식이며 재사용 할 수있는 부분과 실제로 재사용 할 수있는 전문 지식이있는 곳에서만 재사용 할 수 있습니다. 다른 곳에서는 물건을 깨끗하게 만들려고하지만 재사용 가능성에 대해 걱정하지 마십시오. (머리 뒤에서 메모를 작성하여 미래의 일부 시스템에서는 재사용 할 수있는 방법을 알 수 있습니다.)

나는 보라 (이것은 내 개인 신념이다) 기본 및 간단한 대답은 그래서 재사용과 좋은 디자인의 관계는, 재귀하지 않습니다 것을 더 . 좋은 디자인 가이드에 관심이 있다면 이 위키 백과 기사를 확인 하십시오.

좋은 소프트웨어 디자인은 적어도 일부 핵심 부분에서 재사용 할 수 있어야합니다. 시스템 코어를 여러 다른 상황에서 재사용 할 수 있도록 설계하는 것이 극히 복잡하기 때문에 소스 코드를 실제로 재사용하는 사람은 거의 없다고 생각합니다. (그리고 나는 이것을 경험 밖이라고 말하고있다)

필요한 모든 작업을 수행 할 책임이 큰 클래스 (일명 Blob)가 있지만 어떤 종류의 디자인 고려 사항도없는 클래스를 생각해보십시오. 그런 클래스를 가진 대부분의 사람들은 그것을 계속 사용하고 재사용 할 수 있고 디자인이 필요없는 재사용이라는 데 동의해야한다고 생각합니다.

내 설명이 너무 엉망이 아니길 바래

좋은 디자인의 더 좋은 지표는 단일 책임 원칙 및 각 구성 요소의 응집력 유지와 같은 기본 아이디어를 준수하는 것 입니다. 깨끗하고 간결한 인터페이스로 추상화 를 사용 하고 Liskov 대체 교장을 준수 함으로써 재사용 여부를 예측하지 않고 재사용을 권장합니다.

이러한 기본 설계 원칙을 고수하면 코드를 쉽게 테스트 하고 재사용 할 수 있습니다.

좋은 디자인 == 좋은 디자인, 재사용 가능성은 부산물입니다.

재사용 성은 종종 암묵적인 디자인 목표입니다. 당신이 나중에 재사용 될 수 있도록 방법의 구성 요소, 또는 전체 디자인을 만들 수 있다면, 보인다 당신이 그렇게해야한다고 분명. 항상 분명하지 않은 것은 무언가를 재사용 할 수있게하려면 많은 시간과 노력 (및 돈)이 소요될 수 있으므로 재사용 가능성의 이점은 그 비용과 비교되어야한다는 것입니다.

고객이 필요로하는 것보다 2 배나 많은 비용이 소요되고 2 배나 오래 걸리는 재사용 가능한 디자인은 특히 고객이 재사용 할 필요가없는 경우 고객의 관점에서 볼 때 좋은 디자인이 아닙니다.

암시적인 디자인 목표로 간주되는 유사한 속성이 많이 있습니다.

• 비용 최소화

• 개발 시간 최소화

• 복잡성 최소화

• 신뢰성 극대화

이러한 것들은 모두 객관적으로 좋지만 특정 시간에 특정 고객에게 항상 중요하지는 않을 수 있으므로 고객이 원하는 것을 완전히 이해하는 것이 중요합니다 (고객이 상사 일지라도). 이 사실을 상기시켜주는 여러 가지 격언이 있습니다 (예 : "완료된 것보다 완벽 함"및 "좋고 저렴하며 빠름 : 둘 중 하나를 선택하십시오"). 실제로 모든면에서 위대한 것이 항상 필요한 것은 아니라면 모든면에서 훌륭한 소프트웨어를 만드십시오.

제목 질문에 도달하려면 : 아니오 , 재사용 성은 좋은 디자인과 동의어가 아닙니다. 재사용 성은 특정 좋은 디자인의 유용한 구성 요소 일 수 있지만 필요한 경우에만 가능합니다.

반드시 그런 것은 아닙니다. 재사용 할 수없는 무언가를 재사용 할 수있게 만들면 설계가 잘못됩니다.

예를 들어, 회사 고유의 데이터로 가득 찬 파일을 작성하고 해당 데이터를 다른 곳으로 한 번 가져 오는 경우 왜 재사용이 가능합니까?

즉, 프레임 워크에 아직 프레임 워크가 없으면 파일에 쓰는 코드를 재사용해야 할 수도 있습니다. 좋은 디자인이 될 것입니다.

나는 단지 작은 코드 세그먼트만을 설명하기 때문에 아니오라고 말할 것입니다. 유용성이 가장 중요한 곳은 유틸리티 영역의 핵심과 바깥 가장자리에 있으며 그 사이에는 그다지 중요하지 않습니다. 재사용 성이 유용한 품질 디자인 척도라고 생각하는 몇 가지 예를 들어 보겠습니다.

핵심 재료

• 쉽고 일관되게 페이지를 추가 할 수있는 웹 양식 템플릿 (또는 모든 종류의 UI)
• 모든 MVVM 응용 프로그램에 포함될 ViewModel 기본 클래스와 같은 디자인 패턴 도우미

유틸리티 물건

• SMTP 메시지를 보내는 이메일 클래스 (항상 사용)
• GIS 거리 계산기 클래스 (많은 앱에서 사용됨)

대부분의 앱에서 70-80 %를 차지하는 CRUD 제품의 경우 재사용 성이 가치있는 지표라고 생각하지 않습니다.