객체 지향 프로그래밍을 연습하는 방법? [닫은]

나는 항상 절차 언어로 프로그래밍되어 왔으며 현재 객체 방향으로 이동하고 있습니다. 내가 직면 한 주요 문제는 효과적인 방법으로 객체 방향을 연습 할 수있는 방법을 볼 수 없다는 것입니다. 나는 나의 요점을 설명 할 것이다. PHP와 C를 배웠을 때 연습하기가 매우 쉬웠습니다. 무언가를 선택하고 그 알고리즘을 생각하는 것이 중요했습니다.

예를 들어, PHP에서는 "실제로 사람들이 제품을 추가 할 수있는 관리 영역으로 하나의 응용 프로그램을 만들도록하겠습니다"라는 생각과 생각이 중요했습니다. 이것은 매우 쉬웠습니다. 일부 사용자를 등록하고, 사용자를 로그인하고, 제품을 추가하는 알고리즘을 생각해야했습니다. 이것들을 PHP 기능과 결합하여 연습하는 좋은 방법이었습니다.

이제 객체 방향에는 많은 추가 사항이 있습니다. 알고리즘에 대한 생각뿐만 아니라 요구 사항을 더 심층적으로 분석하고, 사용 사례를 작성하고, 클래스 다이어그램, 속성 및 방법을 파악하고, 의존성 주입 및 많은 것들을 설정합니다.

요점은 내가 객체 지향을 배우는 방식에서 좋은 디자인이 중요하고 절차 적 언어에서는 모호한 아이디어로 충분하다는 것입니다. 나는 절차 적 언어로 우리는 디자인 없이도 좋은 소프트웨어를 작성할 수 있다고 말하지는 않는다 . 단지 그것을 실천하기 위해서는 실현 가능하지만, 객체 지향에서는 좋은 디자인 없이는 연습조차 할 수없는 것처럼 보인다.

연습 할 때마다 수많은 요구 사항, 사용 사례 등을 파악해야 할 경우 객체 지향에서 더 나아질 수있는 좋은 방법이 아닌 것 같습니다. 연습 할 때마다 앱에 대한 하나의 아이디어를 가지고 있습니다.

그로 인해 객체 방향을 연습하는 좋은 방법은 무엇입니까?

이제 객체 방향에는 많은 추가 사항이 있습니다.

아뇨 ..

알고리즘에 대한 생각뿐만 아니라 요구 사항을 더 심층적으로 분석하고, 사용 사례를 작성하고, 클래스 다이어그램, 속성 및 방법을 파악하고, 의존성 주입 및 많은 것들을 설정합니다.

객체 지향 프로그래밍을 연습하는 데 필요한 것은 없습니다.

이것은 매우 쉬웠습니다. 일부 사용자를 등록하고, 사용자를 로그인하고, 제품을 추가하는 알고리즘을 생각해야했습니다.

모든 객체 지향 프로그래밍은 이러한 단계를 수행하는 알고리즘을 생각하는 대신이 단계를 수행하는 데 필요한 객체, 원하는 기능, 수행 할 상태 및 노출하려는 인터페이스의 종류에 대해 생각합니다. 사용자에게. 절차 적 프로그래밍에서해야하는 것처럼.

유일한 차이점은 필요한 기능과 작동 방식에 중점을 두지 않고 기능과 상태가 책임으로 그룹화되는 방식과 이러한 책임이 상호 작용하는 방식에 중점을 둔다는 것입니다.

연습하는 방법? 절차 적 프로그래밍 연습과 같은 방법 : 문제를 선택하고 클래스 묶음을 사용하여 문제를 해결하십시오. 그것이 어떻게 빨랐는지 알아 내고 배운 교훈을 반복하십시오.

좋은 질문. 물론 OOP를 실행한다는 것은 실제로 이러한 모든 것 (요구 사항 분석, 사용 사례, 디자인 패턴 등)을 실행하는 것을 의미하며, 이는 사실이며 처음에는 어려워 보일 수 있습니다.

저의 조언은 테스트 중심 개발 과 단일 책임 원칙 이라는 두 가지 사항을 염두에두고 실습 세션을 시작하는 것입니다 .

그런 다음 PHP / C로 시작한 것처럼 시작하십시오. 아이디어를 생각해 내고, 필요한 것이 무엇인지 생각하고 이러한 것들을 차례로 구현하십시오. 그러나 테스트부터 시작해야하며 (그렇지 않으면 테스트 가능성이 즉시 겪는 것처럼 적절한 인터페이스를 정의해야 함) TDD는 적녹 리 팩터주기를 의미합니다. 다시 말해, 약간의 기능이 있으며 일단 작동하면 처음부터 만들지 않은 경우 적절한 OO- 디자인을 얻기 위해 리팩터링합니다 (그렇지 않습니다).

이 리팩토링 단계를 수행 할 때는 항상 SRP를 상기 시키십시오. 객체에 두 번째 책임을 추가했다면 새로운 무언가를 만들 차례입니다.

이와 같이 개발할 때는 최종 솔루션이 처음과 다를 것임을 알아야합니다. 학습 곡선도 다소 가파 릅니다. 예를 들어 팩토리 패턴이 무엇인지 배우지 않고 대신 클래스의 인스턴스를 다른 방식으로 생성하는 무언가의 필요성을 인식합니다. 따라서 객체 지향 디자인 패턴에 대해 전혀 들어 본 적이 없다면 병렬로 디자인을 읽는 것이 좋습니다.

OOP를 막 시작한 경우 실제 시스템에 대해 살펴보고 객체가 무엇인지, 그리고 그 관계가 무엇인지, 지원할 수있는 방법 / 인터페이스와 클래스 계층 구조와 인스턴스화 된 객체의 모음으로 객체를 나타내는 방법 및 객체 소유권 관계 등 (참고 : 위의 "알고리즘"이라는 단어는 언급하지 않았습니다). 그리 많은 당신은 아무것도 코딩에 대해 생각하기 전에 다이어그램을 (UML 또는 유사한 약간 알아보기).

이를 통해 모든 OOP 디자인에서 가장 중요한 단일 분류 인 IS-A 및 HAS-A 관계에 대한 이해도 를 높일 수 있습니다. 그럼에도 불구하고 많은 OOP 언어 프로그래머가 어려움을 겪고있는 것으로 보입니다. ). IS-A / HAS-A를 마스터하면 IS-IMPLEMENTED-IN-TERMS-OF도 있습니다 (IS-KIND-OF-A라고도 보았습니다 : ^)

진지하게, 다음 슈퍼마켓 방문은 누군가가 당신에게 그 장소의 OOP 시뮬레이션을 작성하는 일을했다고 상상해보십시오.

필자가 C 시대에서 기억했던 것 (이전에는 훨씬 먼 시점)은 기능과 절차를 그 책임에 따라 다른 파일로 분리하는 데 사용되었습니다. 나는 그것이 완벽하거나 다른 것을 주장하지는 않지만 실제로 객체 지향 언어로 프로그래밍하기 시작했을 때 좋은 출발점이되었습니다. 아마도 파일을 객체로 변환하는 것으로 시작할 수 있습니다.

OOP가 진행되는 한 실제로는 연습과 개선을위한 노력에 관한 것입니다. 드물게 아무도 처음부터 그것을 제대로 얻지 못합니다. 따라서 반복은 프로젝트 수명주기 동안 발생합니다.

Peter Coad가 1990 년대에 한 것처럼 용어, 객체 지향 분석 및 객체 지향 디자인을 추가해 봅시다 .

이 두 가지를 함께 사용하면 코드 작성 및 테스트 시점에서 프로그래머를 지원할 수 있는 소프트웨어 엔지니어링 OOAD ( OOAD) 가 형성 됩니다. 그런 다음 객체 지향 프로그래밍은 프로젝트 수준에서 지정된 기능적 목표와 디자인 요구 사항을 충족시키기 위해 적절한 수준의 세분성, 프로그래밍 언어 기능을 능숙하게 사용할 수 있습니다.

때로는 한 사람의 프로젝트 인 경우 모든 모자를 착용해야합니다 (그러나 반드시 동시에는 아님). 나는 내 개인 프로젝트를위한 테스트 중심 개발에 열성적인 팬이지만 (Frank의 권장 사항 참조), 객체 지향 소프트웨어 개발에만 관련된 것은 아닙니다.

팀 프로젝트에서 책임 분담이 좋은 것은 성공적인 구현의 열쇠입니다. 객체 지향 디자인 패턴을 능숙하게 사용하면 분석, 데이터 피드 및 비즈니스 로직에 필요한 가시적 인 인터페이스를 제한하여 사용 가능한 프레임 워크를 공유함으로써 팀 이해에 도움이됩니다.

"실제로 사람들이 제품을 추가 할 수있는 관리 영역으로 하나의 응용 프로그램을 구축하겠습니다." 이것은 매우 쉬웠습니다. 일부 사용자를 등록하고, 사용자를 로그인하고, 제품을 추가하는 알고리즘을 생각해야했습니다.

이번에는 사용자 객체와 제품 객체에 대해서만 동일한 작업을 수행하지 않습니까? 또한 절차 및 OO를 모두 지원하는 언어를 사용하는 경우 파일 객체와 같은 절차 표준 라이브러리를 기반으로 객체를 구현할 수 있습니다.