객체 지향 프로젝트를 어떻게 디자인합니까? [닫은]

많은 클래스가 있고 확장 가능 해야하는 큰 프로젝트 (나를 위해)를 작업하고 있지만 프로그램 계획 방법과 클래스 상호 작용 방법을 잘 모르겠습니다.

몇 학기 동안 OOD 과정을 수강하고 많은 것을 배웠습니다. UML 작성 및 요구 사항 문서를 오브젝트 및 클래스로 변환하는 것과 같습니다. 우리는 시퀀스 다이어그램을 배웠지 만 어떻게 든 강의 또는 무언가를 놓쳤습니다.

이전 프로젝트에서 나는 코스에서 배운 방법을 사용하여 시도했지만 일반적으로 "그래, 내가 생각했던 것과 비슷해 보인다"라고 말하자마자 나는 멍청이를 파고 싶지 않다. 새로운 기능.

Steve McConnell의 Code Complete 의 사본이 있습니다. 나는 디자인에 관한 장을 읽었고 내가 찾고있는 정보를 얻지 못하는 것 같습니다. 나는 그것이 절단되고 건조 된 과정이 아니며, 대부분 휴리스틱을 기반으로한다는 것이지만, 그의 모든 정보를 취하여 내 프로젝트에 적용 할 수는없는 것 같습니다.

따라서 높은 수준의 디자인 단계 (프로그래밍을 시작하기 전에) 중에 필요한 클래스 (특히 실제 객체를 기반으로하지 않는 클래스)와 이들이 어떻게 상호 작용할 것인지를 결정하기 위해 수행하는 작업은 무엇 입니까?

특히 나는 당신이 사용하는 방법에 관심이 있습니까? 일반적으로 최종 제품을 밀접하게 나타내는 훌륭하고 깨끗한 디자인을 따르는 프로세스는 무엇입니까?

초기 설계 (클래스 다이어그램으로 가져 오기)에 사용하는 단계는 다음과 같습니다.

1. 요구 사항 수집. 클라이언트와 대화하고 사용 사례를 고려하여 소프트웨어의 기능을 정의하십시오.

2. 개별 사용 사례에 대한 설명을 작성하십시오.

3. 내러티브를 살펴보고 후보 클래스 및 동사 (동작)로서 명사 (사람, 장소, 사물)를 방법 / 행동으로 강조 표시합니다.

4. 중복 명사를 폐기하고 공통 기능을 제거하십시오.

5. 클래스 다이어그램을 작성하십시오. Java 개발자 인 경우 Sun의 NetBeans 6.7에는 다이어그램 엔지니어링 및 왕복 엔지니어링이 가능한 UML 모듈이 있으며 무료입니다. Eclipse (오픈 소스 Java IDE)에는 모델링 프레임 워크가 있지만 경험이 없습니다. 오픈 소스 도구 인 ArgoUML을 사용해 볼 수도 있습니다.

6. OOD 원칙을 적용하여 수업 구성 (공통 기능 제외, 계층 구조 구축 등)

Scott Davies가 말한 내용에 추가 :

1. 시작하기 전에 프로그램의 내용을 반드시 확인하십시오. 당신의 프로그램 은 무엇입니까 ? 그것은 무엇을 할 수 없습니다 합니까? 어떤 문제를 해결하려고합니까?

2. 첫 번째 유스 케이스는 프로그램이 결국 수행 할 모든 것의 세탁 목록이되어서는 안됩니다. 프로그램의 본질을 그대로 담아내는 가장 작은 유스 케이스로 시작하십시오. 예를 들어이 웹 사이트의 경우 핵심 사용 사례는 로그인 , 질문, 질문 에 대한 답변 및 질문과 답변을 볼 수 있습니다 . 평판, 투표 또는 커뮤니티 위키에 관한 것은 아니며 촬영 대상의 본질입니다.

3. 잠재적 인 수업을 할 때, 그들이 어떤 명사를 대표하는지에 대한 것이 아니라 그들이 어떤 책임을 가지고 있는지에 대해서만 생각하십시오. 나는 이것이 프로그램 실행 중에 클래스가 서로 어떻게 관련되는지 알아내는 데 가장 큰 도움이된다는 것을 알았습니다. "개는 동물이다"또는 "강아지는 한 마리의 어머니가있다"와 같은 관계를 생각해 내기가 쉽다. 일반적으로 객체 간의 런타임 상호 작용을 설명하는 관계를 파악하기가 더 어렵습니다. 당신은 프로그램의 알고리즘이 최소한 객체만큼 중요하며 각 클래스의 직업이 무엇인지 철자하면 디자인하기가 훨씬 쉽습니다.

4. 최소한의 사용 사례 및 객체 집합을 얻은 후에는 코딩을 시작하십시오. 많은 일을하지 않고 아마도 쓰레기처럼 보이지만 실제로 가능한 빨리 실행되는 것을 얻으십시오. 그것은 시작점이며, 종이 위에서 광택을 낼 수있는 질문에 답하도록 강요 할 것입니다.

5. 이제 더 많은 유스 케이스를 선택하고 작동 방식을 작성하고 클래스 모델을 수정하고 더 많은 코드를 작성하십시오. 첫 번째 컷과 마찬가지로 의미있는 것을 추가하면서 한 번에 조금만 수행하십시오. 헹구고 반복하십시오.

내 두 센트. 잘하면 유용합니다.

기회가 생겼을 때 나는 보통 "세 개의 반복 규칙"이라고 부르는 것을 사용합니다.

첫 번째 반복 (또는 시작)에서 모델 객체, 알고리즘 및 예상 ( 실제 예상, 아마도 그렇지 않은) 에 따라 응용 프로그램의 일반적인 레이아웃을 고안합니다.예상되는 방향) 디자인 문서를 작성하지는 않지만 여러 사람을 조정해야하는 경우 종속성 분석 및 필요한 시간의 추측과 함께 대략적인 절차 스케치가 필요합니다. 나처럼 더 민첩한 방법을 선호한다면이 단계를 최소한으로 유지하십시오. 강력한 프로그램 단계가 필요한 경우가 있습니다. 특히 프로그램 논리에 대해 모든 것이 알려져 있고 사실이거나 코드의 기능간에 많은 상호 작용을 계획하려는 경우가 있습니다. 이 경우 유스 케이스 또는 사용자 스토리 제공은 특히 GUI 앱에 대한 좋은 아이디어입니다. 명령 줄 앱 및 특히 라이브러리의 경우 개발해야하는 라이브러리에 대해 코딩하고 모양을 확인하는 "프로그램 스토리"를 작성하십시오.

이 첫 번째 반복 후에는 사물이 상호 작용하는 방식, 세부 사항 및 거친 지점을 파악하고 덕트 테이프 패치의 문제를 해결하는 방법에 대해 더 잘 이해할 수 있습니다. 이 경험을 활용하여 너무 큰 것을 개선, 정리, 연마, 분할하고, 너무 조각난 것을 통합하고, 디자인 패턴을 정의 및 사용하고, 성능 병목 현상 및 사소한 보안 문제를 분석 할 수 있습니다. 일반적으로 이러한 모든 변경 사항은 작성한 단위 테스트에는 큰 영향을 주지만 기능 테스트에는 큰 영향을 미치지 않습니다.

이 두 번째 반복을 완료하면 작은 보석, 테스트, 문서화 및 디자인이 잘됩니다. 이제 세 번째 반복을 수행하는 경험과 코드가 모두 확장되었습니다. 새로운 기능과 사용 사례를 추가하여 응용 프로그램을 향상시킵니다. 거친 지점을 찾을 수 있으며 결국 두 번째 반복과 유사한 네 번째 반복으로 들어갑니다. 헹구고 반복하십시오.

이것이 소프트웨어 설계에 대한 일반적인 접근 방식입니다. 짧은 3 개월 반복 및 Agile 개발 요소가 포함 된 나선형 디자인과 유사하여 문제를 배우고 소프트웨어와 해당 응용 분야를 알 수 있습니다. 물론, 어플리케이션 개발자 수백 상황이 조금 더 복잡이보다 참여 너무 커서 그렇다면, 확장 성의 문제, 그러나 결국 나는 아이디어가 항상 같은, 추측 분할 등의 impera .

요약하자면 :

1. 반복 1에서, 당신은 그것을 맛보고 배우고
2. 두 번째 반복에서는 제품을 정리하고 미래를 위해 준비합니다
3. 세 번째 반복에서는 새로운 기능을 추가하고 더 많은 정보를 얻습니다.
4. 고토 2

이것에 관해 내가 아는 가장 흥미로운 소스는 Bertrand Meyer 의 Object Oriented Software Construction, Part 2 의 Part D입니다 .

파트 D : 객체 지향 방법론 : 방법을 잘 적용

19 : 방법론, 20 : 디자인 패턴 : 다중 패널 대화식 시스템, 21 : 상속 사례 연구 : 대화식 시스템에서 "실행 취소", 22 : 클래스를 찾는 방법 , 23 : 클래스 디자인의 원칙, 24 : 상속 잘 사용 , 25 : 유용한 기술, 26 : 스타일 감각, 27 : 객체 지향 분석, 28 : 소프트웨어 구성 프로세스, 29 : 방법 교육

흥미롭게도 22 장 . 수업을 찾는 방법 은 온라인에서 볼 수 있습니다.

반복되는 것은 아니지만 완전히 사실입니다. 데이터를 이해하십시오.

OOP의 경우 클래스는 중요한 정보와 상호 작용 방식을 설명해야합니다.

데이터의 행동과 수명을 잘 설명하는 정신 모델이 있다면 수업을 쉽게 펼칠 수 있습니다.

이것은 단순히 다음의 확장입니다. 무엇을하려고하는지 정확히 아십시오.

행동 중심 개발을 사용해보십시오. 당신의 오래된 습관을 깰 수는 없지만, BDD는 실제 세계에서 발전 할 때 가장 좋은 방법이라는 것을 알았습니다.

http://behaviour-driven.org/

대규모 프로젝트의 문제점은 컴포넌트 간의 모든 상호 작용을 감독 할 수 없다는 것입니다. 따라서 프로젝트의 복잡성을 줄이는 것이 중요합니다. 이 단계의 설계에서는 클래스 및 시퀀스 다이어그램이 너무 상세합니다.

먼저 더 높은 추상화 수준에서 생각하십시오. 주요 구성 요소와 그 책임 (다른 구성 요소와의 인터페이스)에 대해 생각하고 영감을 얻기위한 일부 아키텍처 패턴을 살펴보십시오 (디자인 패턴이 아니라 너무 낮은 수준입니다. MVC 및 다중 계층은 아키텍처 패턴의 예입니다). 합리적으로 큰 프로젝트의 경우 이러한 뷰에는 약 3-5 개의 구성 요소가 있어야합니다.

그런 다음에야 특정 구성 요소를 확대하여 디자인하려고합니다. 이제 우리는 디자인 패턴과 클래스 다이어그램의 수준에 있습니다. 다른 구성 요소 중 하나에 책임을 추가해야하는 경우 프로젝트의이 부분에 집중하십시오. 문서 / 할 일 목록에 추가하십시오. 이 시점에서 그것들이 너무 빨리 변하는 의미에 대해 생각하면서 시간을 낭비하지 말고 디자인이 더 견고한시기를 검토하십시오.

아직 구현되지 않은 구성 요소 인터페이스를 구현하고 간단하지만 유용한 응답을 생성하는 코드 조각을 갖는 것이 현명하지만이 시점에서 각 구성 요소를 완전히 디자인 할 필요는 없습니다. 이런 방식으로 한 번에 하나의 구성 요소 개발 (및 설계)을 시작하고 적절한 수준으로 테스트 할 수 있습니다.

물론 새 구성 요소가 완성되면 계속 진행하기 전에 구성 요소가 서로 어떻게 통합되는지 테스트해야합니다.

간단히 말해서 : OO와 정보 은닉 원칙을 취하여 다른 차원으로 끌어 올리십시오!

추신 : 디자인하는 동안 많은 스케치를하십시오. 실제 아키텍처와 같습니다!

PPS : 다른 각도에서 문제에 접근하려고 노력하십시오. 상자 밖에서 생각하십시오 (상자가 갈 길이지만), 동료와 논의하는 것이 매우 유용 할 수 있습니다 ... 그리고 점심 식사에 대해 이야기 할 것이 있습니다.

실제 프로젝트에서 합리적으로 성공한 기술은 Wirfs-Brock의 책에서 영감을 얻은 책임 중심의 디자인입니다.

최고 수준의 사용자 스토리로 시작하고 동료와 함께 화이트 보드에서 그들이 암시하는 높은 수준의 상호 작용을 스케치하십시오. 이것은 큰 모듈이 무엇인지에 대한 첫 번째 아이디어를 얻습니다. 그리고 놀이와 같은 높은 수준의 CRC 카드의 반복 또는 두 가지 주요 구성 요소, 구성 요소 및 상호 작용 방식을 안정화해야합니다.

그런 다음, 책임이 크거나 복잡한 경우, 상위 레벨 상호 작용으로 식별 된 각 주요 조작에 대해 모듈 내부의 상호 작용을 수행하여 오브젝트가 될 수있을 정도로 작고 단순한 항목이 될 때까지 해당 모듈을 세분화하십시오. .

언제 중지해야할지 아는 것은 판단의 문제입니다 (경험 만 제공).

디자인 패턴

창조 디자인 패턴

싱글 톤-하나의 클래스 인스턴스 만 작성하고 오브젝트에 대한 글로벌 액세스 지점을 제공하십시오.

팩토리 (Factory Method의 단순화 된 버전)-인스턴스화 로직을 클라이언트에 노출시키지 않고 객체를 생성하고 공통 인터페이스를 통해 새로 생성 된 객체를 참조합니다.

팩토리 메소드-오브젝트를 작성하기위한 인터페이스를 정의하지만 서브 클래스가 인스턴스화 할 클래스를 결정하고 공통 인터페이스를 통해 새로 작성된 오브젝트를 참조하도록합니다.

Abstract Factory-클래스를 명시 적으로 지정하지 않고 관련 객체 패밀리를 작성하기위한 인터페이스를 제공합니다.

Builder-객체를 생성하기위한 인스턴스를 정의하지만 서브 클래스가 인스턴스화 할 클래스를 결정하게하고 구성 프로세스를보다 세밀하게 제어 할 수 있습니다.

프로토 타입-프로토 타입 인스턴스를 사용하여 작성할 오브젝트의 종류를 지정하고이 프로토 타입을 복사하여 새 오브젝트를 작성하십시오.

행동 디자인 패턴

책임 체인-요청의 발신자를 수신자에게 첨부하는 것을 방지하여 다른 방법으로도 요청을 처리 할 수 ​​있습니다. -개체가 체인의 일부가되고 개체 중 하나가 처리 할 때까지 체인을 통해 한 개체에서 다른 개체로 요청이 전송됩니다.

명령-개체에 요청을 캡슐화하고, 요청이 다른 클라이언트의 매개 변수화를 허용하고, 요청을 대기열에 저장할 수 있습니다.

통역사-언어가 주어지면, 표현을 사용하여 언어의 문장을 해석하는 해석기 / 문법을 언어로 표현, 도메인을 언어로, 언어를 문법으로, 문법을 계층 적 객체 지향 디자인으로 해석하는 해석기와 함께 표현을 정의하십시오.

반복자-기본 표현을 노출시키지 않고 집계 오브젝트의 요소에 순차적으로 액세스하는 방법을 제공합니다.

중재자-일련의 객체가 상호 작용하는 방식을 캡슐화하는 객체를 정의합니다. 중재자는 객체가 서로 명시 적으로 언급되지 않도록하여 느슨한 결합을 촉진하며, 상호 작용을 독립적으로 변화시킬 수 있습니다.

관찰자-하나의 오브젝트가 상태를 변경할 때 모든 종속 항목에 자동으로 알리고 업데이트되도록 오브젝트 간의 일대 다 종속성을 정의하십시오.

전략-알고리즘 제품군을 정의하고 각 알고리즘을 캡슐화하여 상호 교환 가능하게합니다. 전략을 사용하면 알고리즘을 사용하는 클라이언트와 알고리즘이 독립적으로 달라질 수 있습니다.

템플릿 방법-작업에서 알고리즘의 골격을 정의하여 일부 단계를 서브 클래스로 연기 / 템플릿 방법을 사용하면 서브 클래스에서 알고리즘의 특정 단계를 알고리즘 구조를 변경하지 않고도 재정의 할 수 있습니다.

방문자-오브젝트 구조의 요소에 대해 수행 할 조작을 나타냅니다. / 방문자는 조작하는 요소의 클래스를 변경하지 않고 새 조작을 정의 할 수 있습니다.

Null Object-지정된 유형의 개체가없는 경우 대리자로 개체를 제공합니다. Null 개체 패턴은 공동 작업자로부터 세부 정보를 숨기면서 지능적인 동작을 수행하지 않습니다.

구조 설계 패턴

어댑터-클래스의 인터페이스를 클라이언트가 기대하는 다른 인터페이스로 변환하십시오. / 어댑터는 호환되지 않는 인터페이스로 인해 클래스가 함께 작동하도록합니다.

브리지-개체를 트리 구조로 작성하여 전체 계층 구조를 나타냅니다. / Composite를 사용하면 클라이언트가 개별 객체와 객체 구성을 균일하게 처리 할 수 ​​있습니다.

합성-개체를 트리 구조로 구성하여 전체 계층 구조를 나타냅니다. / Composite를 사용하면 클라이언트가 개별 객체와 객체 구성을 균일하게 처리 할 수 ​​있습니다.

데코레이터-객체에 동적으로 추가 책임을 추가합니다.

Flyweight-공유를 사용하여 상태의 다른 부분이 다를 수있는 내부 상태의 일부를 공통으로 갖는 많은 수의 개체를 지원합니다.

Memento-캡슐화를 위반하지 않고 오브젝트의 내부 상태를 캡처하여 필요할 때 오브젝트를 초기 상태로 복원하는 수단을 제공합니다.

프록시-개체가 개체에 대한 참조를 제어 할 수 있도록 "자리 표시 자"를 제공합니다.

BlueJ 와 ActiveWriter 를 사용 하여 객체를 배우고 이해하는 것이 좋습니다. 권장 도서는 훌륭한 자료이기도합니다.

에서 위키 백과 :

BlueJ는 Java 프로그래밍 언어를위한 통합 개발 환경으로, 주로 교육 목적으로 개발되었지만 소규모 소프트웨어 개발에도 적합합니다.

또한 UML을 사용하며 객체 모델링에 대한 몇 가지 사항을 이해하는 데 유용한 리소스였습니다.

대체 텍스트 http://www.ryanknu.com/ryan/bluej.png

ActiveWriter 는 엔터티 및 관계를 모델링하는 도구이며 코드도 생성하며 쉽게 변경할 수 있습니다. 시간을 절약하고 민첩한 개발에 매우 ​​적합합니다.

_{(출처 : altinoren.com )}

우선 디자인은 당신의 영혼에서 나옵니다. 당신은 당신의 모든 섬유에 의해 그것을 느껴야합니다. 나는 보통 무언가를 시작하기 전에 2 ~ 3 개월 동안 그것을 걸으며 그냥 길을 걸어갑니다 (실제로). 그리고 생각. 걷기는 좋은 명상입니다. 따라서 집중력을 높일 수 있습니다.

둘째-자연스러운 객체 계층이 존재하는 경우에만 OOP와 클래스를 사용하십시오. 인위적으로 '나사'하지 마십시오. 엄격한 계층 구조가없는 경우 (대부분의 비즈니스 응용 프로그램 에서처럼) 절차 / 기능을 수행하거나 최소한 격리 된 접근자가있는 데이터 컨테이너로만 개체를 ​​사용하십시오.

그리고 마지막-이것을 읽으십시오 : 창의적 사고의 알고리즘

그냥 인용 http://www.fysh.org/~katie/computing/methodologies.txt

RUP의 핵심에는 OO 디자인 재능을 사용해야하는 작은 영역이 있습니다. 그렇지 않은 경우, 100m을 운영하는 방법론과 같습니다.

"1 단계 : 정말 빠른 달리기에 대해 쓰십시오. 2 단계 : 가서 경마장의 계획을 세우십시오. 3 단계 : 정말 타이트한 라이크라 반바지를 사십시오. 4 단계 : 정말, 정말, 정말 빨리 달리십시오. 5 단계 : 첫 줄을 넘어서십시오. "

4 단계는 힘든 단계입니다. 그러나 1,2,3 및 5에 중점을두면 아무도 눈치 채지 못할 수 있으며 100m이라는 "비밀"이 있다고 생각하는 운동 선수가 될 수있는 방법론을 판매하여 많은 돈을 벌 수 있습니다 주자

많은 저자들이 책을 쓰는 데 사용하는 질문을했습니다. 수많은 방법론이 있으며 "가장 예쁜"것처럼 보이는 방법을 선택해야합니다. Eric Evans의 "도메인 기반 디자인" 을
추천 할 수 있습니다 . 또한 dddcommunity.org 사이트를 확인하십시오 .

나는 여기의 대답이 매우 달라야 한다고 생각합니다. 에 대한 실제 경험에 따라 .

1 년 또는 2 년의 근무 경험이 있다면 그 시점으로 가야 합니다. 합니다. 데이터를 실제로 알고 있고 무엇을 하려는지 정확히 이해하는 시점까지 가야합니까?

예, 실제 세계에서 5 년 이상 근무한 경우 수많은 소프트웨어 개발 프로세스 모델 또는 기술 중 하나를 선택할 수 있습니다.

그러나 책을 읽는 것만으로는 경험이 없습니다. 훌륭한 지도력 아래 좋은 그룹에서 일하면서 배워야합니다.

그것이 가능하지 않으면 혼자서해야합니다. 아마도 매우 불쾌한 코드를 코딩하고, 오류를 배우고, 모두 덤프하고, 더 나은 코드를 코딩하는 등의 방법으로 반복을 시작하십시오.

코드베이스에 대해 많이 배울 것입니다. 도구는 도구이며 아무것도 가르쳐주지 않습니다.

프로젝트에 대한 도메인 전문 지식이 있다면 은행 업무처럼 작업 할 것입니다. 객체를 쉽게 구성 할 수 있으며, 매일 그 기능이 어떻게 향상되는지 알고 있습니다.

해당 전문 지식이없는 경우 해당 전문 지식을 가진 사람과 협력하여 해당 아이디어를 기술적 세부 사항으로 변환하십시오.

프로젝트 디자인을 구성하는 방법이 혼란 스러울 경우 "실용적인 프로그래머"책을 빈번히 따르십시오. 나는 전에도 같은 상황에 처해있었습니다. 그 책에서 한 장을 읽으십시오. 차이점을 보게 될 것입니다. 소프트웨어 개발자로서 생각하는 방식이 바뀔 것입니다.

1. 연구 및 마스터 디자인 패턴.
2. 다음으로 도메인 기반 설계에 대해 알아보십시오.
3. 그 후, 요구 사항 수집을 배우십시오

몇 학기 동안 OOD 과정을 수강하고 많은 것을 배웠습니다. UML 작성 및 요구 사항 문서를 오브젝트 및 클래스로 변환하는 것과 같습니다. 우리는 시퀀스 다이어그램을 배웠지 만 어떻게 든 강의 또는 무언가를 놓쳤습니다.

4. 3 단계에 대해 알고 있습니다. 마스터해야합니다. 제 2의 본성이되도록 많은 연습을 통해 말입니다. 그것은 당신이 배우는 방법이 단순히 우리가 가진 방식과 반대이기 때문입니다. 그래서 당신은 그것을 정말로 마스터해야합니다. 그렇지 않으면 항상 자신이 원래의 일을하는 방식으로 되돌아 간다는 것을 알게 될 것입니다. 이것은 몇 가지 시도 후에 많은 Java 개발자가 포기하는 Test Driven Process와 같습니다. 그들이 완전히 마스터하지 않는 한, 그것은 단지 그들에게 부담입니다

5. 특히 대체 과정에 대한 사용 사례를 작성하십시오. 대체 과정은 개발 시간의 50 % 이상을 차지합니다. 일반적으로 PM이 예를 들어 로그인 시스템을 생성하는 등의 작업을 할당 할 때 직진 상태라고 생각하면 완료하는 데 하루가 걸릴 수 있습니다. 그러나 그는 당신이 고려해야 할 사항을 결코 고려하지 않습니다. 1. 사용자 암호가 틀린 경우 어떻게 2. 사용자 암호가 3 번 틀린 경우 3. 사용자가 사용자 이름을 입력하지 않으면 어떻게해야합니까? 당신은 그들을 나열하고 그것을 PM에 보여주고 마감 시간을 다시 정하도록 요청해야합니다.

나는 이것이 대답이 아닌 것이 두려워 사람들이 듣고 싶어하는 . 어쨌든 내 의견을 말하겠습니다.

OOP는 상위 패러다임이 아닌 패러다임 중 하나로 간주되어야합니다. OOP는 GUI 라이브러리 개발과 같은 특정 종류의 문제를 해결하는 데 좋습니다. 또한 일반적으로 대규모 소프트웨어 회사가 따르는 소프트웨어 개발 스타일에 적합합니다. 엘리트 디자이너 또는 건축가 팀은 소프트웨어 디자인을 UML 다이어그램 또는 기타 유사한 매체 및 덜 조명 된 팀으로 구성합니다. 개발해당 디자인을 소스 코드로 변환하십시오. OOP는 혼자 일하거나 재능있는 프로그래머로 구성된 소규모 팀과 함께 일하는 경우 큰 이점이 없습니다. 그런 다음 여러 패러다임을 지원하는 언어를 사용하는 것이 좋으며 프로토 타입을 빠르게 만들 수 있습니다. Python, Ruby, Lisp / Scheme 등이 좋은 선택입니다. 프로토 타입은 디자인입니다. 그런 다음 개선하십시오. 당면한 문제를 해결하기 위해 가장 좋은 패러다임을 사용하십시오. 필요한 경우 C 또는 다른 시스템 언어로 작성된 확장으로 핫스팟을 최적화하십시오. 이 언어 중 하나를 사용하면 확장 성이 향상됩니다프로그래머 수준뿐만 아니라 사용자 수준에서도 무료입니다. Lisp와 같은 언어는 코드를 동적으로 생성하고 실행할 수 있으므로 사용자는 소프트웨어 자체가 코딩 된 언어로 작은 코드 스 니펫을 작성하여 응용 프로그램을 확장 할 수 있습니다! 또는 C 또는 C ++로 프로그램을 작성하기로 선택한 경우 Lua와 같은 작은 언어에 대한 인터프리터를 포함시키는 것이 좋습니다. 해당 언어로 작성된 플러그인으로 기능을 노출하십시오 .

OOP와 OOD는 대부분 과잉 설계의 대상이되는 소프트웨어를 만든다고 생각합니다.

요약하면 소프트웨어를 작성하는 가장 좋은 방법은 다음과 같습니다.

1. 동적 언어를 사용하십시오.
2. 해당 언어 자체로 디자인 (시제품)을 작성하십시오.
3. 필요한 경우 C / C ++를 사용하여 특정 영역을 최적화하십시오.
4. 구현 언어 자체의 인터프리터를 통해 확장 성을 제공하십시오.

마지막 기능을 통해 소프트웨어는 특정 사용자 (나 자신을 포함하여) 요구 사항에 쉽게 적응할 수 있습니다.

TDD (Test-Driven Design)를 사용합니다. 테스트를 먼저 작성하면 실제로 깨끗하고 정확한 디자인으로 이어질 수 있습니다. http://en.wikipedia.org/wiki/Test-driven_development를 참조하십시오 .

디자인 패턴을 배우십시오 . 지난 2 년 동안 OOP에 관한 개인적인 혁명이었습니다. 책을 받으세요. 나는 당신에게 이것을 추천 할 것입니다 :

헤드 퍼스트 디자인 패턴

Java로되어 있지만 모든 언어로 확장 할 수 있습니다.

솔직히, 좋은 단계는 돌아가서 순서도 및 순서도를 보는 것입니다. 이를 수행하는 방법을 보여주는 훌륭한 사이트가 많이 있습니다. 프로그램이 입력, 계산 및 출력 해야하는 것을 정확히 알고 각 단계를 프로그램의 한 부분으로 나눌 수 있으므로 프로그램을 클래스로 나누는 방법을 볼 때 귀중한 것으로 나타났습니다.

작성 하려는 소프트웨어를 디자인하기 위해 어떤 워크 플로를 수행해야합니까?

유용한 기술 중 하나는 고유 한 문제 설명을 실제 세계에서 찾을 수있는 것과 관련시키는 것입니다. 예를 들어, 세상을 폭풍으로 몰아 낼 복잡한 의료 시스템을 모델링하고 있습니다. 이를 모델링하기 위해 쉽게 호출 할 수있는 예가 있습니까?

과연. 사이드 약국이 어떻게 운영되는지 또는 의사의 방을 관찰하십시오.

도메인 문제를 이해하기 쉬운 것으로 가져 오십시오. 당신이 관련시킬 수있는 것.

그런 다음 도메인 내에서 "플레이어"일단 명백한 나타나기 시작, 당신은 당신의 코드가 모델의 "공급자"입니다 즉 접근 방식을 모델링 「프로 바이더 소비자 "에 대한 코드, 옵트를 모델로 시작하고, 당신 은"소비자 있습니다 ".

도메인과 관련되고 높은 수준에서 이해하는 것은 모든 디자인의 핵심 부분입니다.

수업 구조를 디자인하는 모험 중에 의사 코드를 작성하는 것이 도움이된다는 것을 알게되었습니다. 그 의미는 다음과 같습니다. 저는 응용 프로그램 코드의 일반적인 일부 조각을 가장 높은 수준에서 "쓰기"로 시작하고, 그것을 사용하고, 실제로 프로그래머로서 사용하고 싶은 요소를 발견합니다. 모듈의 일반적인 구조와 상호 작용을 설계하는 데 아주 좋은 출발점입니다. 몇 번의 반복 후에 전체 구조가 전체 클래스 시스템처럼 보이기 시작합니다. 코드의 일부를 디자인 할 수있는 매우 유연한 방법입니다. 이를 프로그래머 지향 디자인이라고 부를 수 있습니다.