더 나은 객체 지향 프로그래밍을 어떻게 연습 할 수 있습니까? [닫은]

나는 수년 동안 객체 지향 언어로 프로그래밍을 해왔지만 동료들이 부러워하는 일을 비밀리에 봅니다. 많은 사람들이 내가 아무리 노력해도 내가 가지고 있지 않은 내면의 OO 본능을 가지고있는 것 같다. 나는 OO에 대한 좋은 책을 모두 읽었지만 여전히 그것을 깨뜨리지 않는 것 같습니다. 프로 축구 선수가되기 위해 110 %를 바 쳤지 만 그것을 할 수있는 타고난 재능이 없었던 사람처럼 느껴집니다. 진로를 바꿀 생각을하고 있습니다. 어떻게해야합니까?

나는 OO 프로그래밍에 덜 집중하고 OO 디자인 에 더 집중한다고 말하고 싶다 . 종이와 연필 (또는 UML 모델링 도구)을 잡고 화면에서 벗어나십시오.

시스템을 설계하는 방법을 연습함으로써 객체 관계에 대한 자연스러운 느낌을 얻을 수 있습니다. 코드는 디자인의 부산물 일뿐입니다. 코드가 아닌 형태로 다이어그램을 그리고 애플리케이션을 모델링합니다. 관계는 무엇입니까? 모델은 어떻게 상호 작용합니까? 코드에 대해 생각조차하지 마십시오.

디자인에 시간을 투자했다면 ... 코드로 번역하세요. 좋은 OO 디자인에서 코드를 얼마나 빨리 작성할 수 있는지에 놀라실 것입니다.

많은 디자인 연습을 마친 후에는 모듈화되거나 추상화 될 수있는 공통 영역을보기 시작하고 디자인과 코드 모두에서 개선 된 것을 볼 수 있습니다.

가장 쉬운 방법은 SOLID, DRY, FIT, DDD, TDD, MVC 등과 같은 개념을 배우는 것입니다.이 두문자어를 찾아 보면 다른 많은 토끼 구멍을 찾을 수 있으며 일단 읽기를 마치면 더 나은 객체 지향 프로그래밍이 무엇인지 잘 이해하십시오!

SOLID 팟 캐스트 : http://www.hanselminutes.com/default.aspx?showID=168 , http://www.hanselminutes.com/default.aspx?showID=163

고체 분석 : http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

건조 : http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

FIT : http://www.netwellness.org/question.cfm/38221.htm

DDD : http://dddcommunity.org/

DDD 필수 읽기 : http://www.infoq.com/minibooks/domain-driven-design-quickly

TDD : http://en.wikipedia.org/wiki/Test-driven_development

MVC : http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

그리고 예, 소매를 걷어 올리고 코딩하는 것은 항상 좋은 생각입니다. 현재 능력을 최대한 활용하여 작은 프로젝트를 만드십시오. 그런 다음 위에서 기사를 읽으십시오. 그런 다음 방금 읽은 내용의 요구 사항을 충족하도록 코드를 리팩터링합니다. 코드를 완전히 리팩토링 할 때까지 반복하십시오. 마지막에는 OO가 무엇인지 알아야 할뿐만 아니라 왜 OO가 중요한지, 어떻게 처음으로 얻을 수 있는지 설명 할 수 있어야합니다. 리팩터링하는 방법을 배우는 것도 좋은 코드의 핵심입니다. 지금은 내일이 옳지 않습니다.

너무 많은 사람들이 코딩을 먼저 생각하고 객체를 마지막으로 생각합니다.

원하는 모든 책을 읽을 수 있지만 그것은 연습과 특정 방법론이 필요한 객체 지향 방식으로 생각하는 방법을 가르쳐주지는 않습니다.

1. 저에게 도움이 된 몇 가지 방법은 다음과 같습니다. 직장을 떠나 열린 마음 으로 모든 것을 사물로보고 연습 할 수 있습니다 . 이러한 개체를보고 어떻게 프로그래밍할지 궁금해하지 말고 속성과 함수로만 보며 서로 관련되거나 상속되는 방식을 확인하십시오. 예를 들어, 사람을 볼 때 이들은 객체이므로 클래스를 나타냅니다. 그들은 머리 색깔, 피부색, 키 등과 같은 속성을 가지고 있습니다. 그들은 또한 특정한 기능을합니다. 그들은 걷고, 말하고, 수면 등을합니다.이 사람들이하는 일부 기능은 결과를 반환합니다. 예를 들어 작업 함수는 달러 금액을 반환합니다. 모든 것이 객체이기 때문에 당신이 보는 모든 것으로 이것을 할 수 있습니다. 자전거, 자동차, 스타 등

2. 프로젝트를 코딩하기 전에 포스트잇과 드라이 지우기 보드를 사용하여 디자인하십시오. 이것은 당신이 이것에 익숙해 질 때까지 좋은 연습이 될 것입니다. 특정 개체 / 기능 / 속성을 생각하십시오. 각 항목에는 자체 포스트잇이 있습니다. 건조 지우기 보드에 계층 구조로 배치하십시오. 이와 관련하여 함수 / 속성은 개체 아래에 배치됩니다. 다른 개체가있는 경우 해당 개체에 대해 동일한 작업을 수행하십시오. 그런 다음 자신에게 물어보십시오. 메모 (객체 / 기능 / 속성)가 서로 관련되는 게시물을 작성하십시오. 두 개체가 동일한 기능을 사용하는 경우 상위 개체 (포스트잇 메모)를 만들고 새 메모 아래에 재사용 가능한 기능이있는 다른 개체 위에 놓습니다. 건조 지우기 마커를 사용하여 두 개의 자식 개체에서 부모까지 선을 그립니다.

3. 이 모든 것이 완료되면 클래스 작동 방식의 내부에 대해 걱정하십시오.

제 제안은 다른 것을 배우는 것입니다.

함수형 프로그래밍을 배우고 그로부터 배운 것을 OOP에 적용하십시오. C ++를 알고 있다면 일반 프로그래밍을 사용해보십시오.

비 객체 지향 언어를 배우십시오.

이 모든 것을 사용해야하기 때문에 (당신은해야한다), 또는 OOP를 완전히 대체해야하기 때문 ( 아마도 안 될 것 같다 )뿐만 아니라, 이것들의 교훈을 OOP에도 적용 할 수 있기 때문이다.

OOP의 비밀은 그것을 사용하는 것이 항상 의미가있는 것은 아니라는 것 입니다. 모든 것이 수업이 아닙니다. 모든 관계 나 행동의 일부가 클래스로 모델링되어야하는 것은 아닙니다.

맹목적으로 OOP를 적용하려고 시도하거나 가능한 한 최고의 OOP 코드를 작성하려고 노력하면 너무 많은 수준의 추상화와 간접 및 유연성이 거의없는 엄청난 오버 엔지니어링 혼란이 발생하는 경향이 있습니다.

좋은 OOP 코드를 작성하려고하지 마십시오. 좋은 코드를 작성하십시오. 그리고 그 목표에 기여할 때 OOP를 사용하십시오.

많은 분야에서 모든 종류의 "유레카"순간이 있습니다.

나는 고등학교 기하학에서 좌절감을 느꼈던 것을 기억합니다. 증명의 각 단계에 어떤 정리를 적용해야할지 몰랐습니다. 그러나 나는 그것을 지켰다. 나는 각 정리를 자세히 배웠고 그것들이 다른 예제 증명에 어떻게 적용되는지 연구했습니다. 각 정리의 정의뿐만 아니라 사용 방법을 이해하면서 필요에 따라 꺼낼 수있는 익숙한 기술의 "도구 상자"를 만들었습니다.

프로그래밍도 마찬가지라고 생각합니다. 이것이 알고리즘, 데이터 구조 및 디자인 패턴을 연구하고 분석하는 이유입니다. 책을 읽고 기술의 추상적 인 정의를 얻는 것만으로는 충분하지 않습니다. 당신도 그것을 실제로 봐야합니다.

따라서 직접 작성하는 것 외에도 더 많은 코드를 읽어 보십시오. 이것이 오픈 소스의 아름다움 중 하나입니다. 많은 코드를 다운로드하여 공부할 수 있습니다. 모든 코드가 좋은 것은 아니지만 나쁜 코드를 공부하는 것은 좋은 코드를 공부하는 것만 큼 교육적 일 수 있습니다.

다른 언어를 배우십시오! Java 만 사용하는 대부분의 개발자는 언어 기능과 개념을 분리 할 수 ​​없기 때문에 OO에 대한 이해가 제한적입니다. 아직 모르는 경우 파이썬을 살펴보십시오. 파이썬을 알고 있다면 Ruby를 배우십시오. 또는 기능 언어 중 하나를 선택하십시오.

aswer가 귀하의 질문에 있습니다.)

연습, 연습, 연습.

자신의 코드를 검토하고 실수로부터 배우십시오.

TDD 는 OOP를 포함한 전반적인 기술 향상에 가장 큰 도움이되었습니다.

더 많은 코드를 작성할수록 특정 프로그래밍 관행의 함정을 더 많이 알 수 있습니다. 충분한 시간과 충분한 코드를 사용하면 이러한 함정의 경고 신호를 식별하고이를 피할 수 있습니다. 때로는 코드를 작성할 때 내가 필요로하는 작업을 수행하더라도이를 수행하는 더 좋은 방법이있을 수 있다고 말하면서이 가려움증을 마음 속에 떠 올릴 것입니다. 내 가장 큰 프로그래밍 약점 중 하나는 "과도하게 분석"하여 개발 시간을 극적으로 늦추는 것입니다. 나는 디자인에 조금 더 많은 시간을 소비함으로써 이러한 "가려움증"을 방지하려고 노력하고 있는데, 이는 일반적으로 코드 작성 시간을 훨씬 줄여줍니다.

... 동료들이 부러워하는 일을 비밀리에 봅니다. 많은 사람들이 내가 가지고 있지 않은 내면의 OO 본능을 가지고있는 것 같습니다. 아무리 노력해도 ...

여기에서 자신의 질문에 답한 것 같습니다. 좋은 코드를 읽는 것이 좋은 시작이고 좋은 코드를 이해하는 것이 훨씬 낫지 만 좋은 코드를 얻기위한 단계를 이해하는 것이 가장 좋습니다. 부러워하는 코드를 발견하면 작성자에게 해당 솔루션에 어떻게 도달했는지 물어볼 수 있습니다. 이것은 전적으로 동료와의 관계뿐만 아니라 작업 환경에 따라 다릅니다. 어쨌든 누군가 내가 작성한 코드의 사고 과정에 대해 물어 보면 주저하지 않고 그들에게 말해줍니다. 왜냐하면 그들이 저를 위해 똑같이하기를 원하기 때문입니다.

언어 설계자는 "객체 지향 프로그래밍"을 다양한 방식으로 해석했습니다. 예를 들어 OOP라는 용어를 처음 사용한 사람인 Alan Kay가 어떻게 정의했는지보십시오.

나에게 OOP는 메시지, 로컬 보존 및 보호 및 상태 프로세스의 숨김, 모든 것의 극단적 인 지연 바인딩만을 의미합니다. Smalltalk 및 LISP에서 수행 할 수 있습니다. 이것이 가능한 다른 시스템이있을 수 있지만 나는 그것들을 알지 못합니다.

( http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en 에서 인용 ).

그가 Java 및 C ++ OOP 언어를 고려하지 않는 것이 이상하게 보일 수 있습니다! 그러나 최초이자 최고의 OOP 언어 (Smalltalk) 중 하나를 설계 한 그는 그 자체로 타당한 이유가 있습니다. Alan Kay가 Lisp를 Java가 아닌 객체 지향 언어로 간주 한 이유는 무엇입니까? 이 질문은 OOP를 이해한다고 주장하는 사람의 진지한 고려를 요구합니다.

Erlang 은 OOP 의 완전히 다른 구현 을 가지고 있으며 Scheme 에는 또 다른 구현이 있습니다. 이러한 모든 대안 적 견해를 고려할 가치가 있습니다. 가능하다면이 모든 언어를 배우십시오! 그것은 당신에게 더 넓은 시야를 제공하고 새롭고 강력한 도구를 손에 넣고 더 나은 프로그래머가 될 것입니다.

이 기사의 Smalltalk, Scheme 및 Erlang 에서 빌린 아이디어를 기반으로 OOP 언어 구현에 대한 실험을 요약했습니다 .

       public void MasteryOfOOP() 
    { 
       while(true)

        /* My suggestion is: */
     DO: find a lot of well-written object oriented code and read it.  Then 
try to use the insights from it on your own coding.  Then do it again.  Then 
have a colleague who is a good OOP look at it and comment. Maybe post a chunk 
of your code on SO and ask for how it could be improved.

        Then read some more of those books.  Maybe they make a little more 
sense now...?

        Now go back to the top of this post, and do it again. 

        Repeat Forever.

        }
    }

객체 지향 시스템을 설계하는 방법을 잃어버린 경우 데이터부터 시작하십시오. 추적해야 할 항목과 자연스럽게 결합되는 정보 (예 : 자동차 그룹 모델의 모든 사양이 잘 결합 됨)를 파악합니다.

추적하기로 결정한 이러한 각 유형은 클래스가됩니다.

그런 다음 특정 작업 (예 : 자동차 모델을 폐기 된 것으로 표시)을 실행하거나 특정 질문 (예 : 특정 연도에 특정 자동차 모델이 몇 대 판매되었는지 질문)을 수행 할 수 있어야 할 때로드합니다. 그 기능은 가장 많이 상호 작용하는 클래스에 적용됩니다.

일반적으로 주어진 코드가 클래스 구조에 상주 할 수있는 매우 자연스러운 장소가 항상 있어야합니다. 없는 경우 구조를 구축해야하는 장소가 있다는 신호입니다.

개체에 대한 정보가 너무 많습니다. 가장 중요한 것은 기본을 습득하는 것이며 모든 것이 더 쉽게 제자리에 배치됩니다.

여기에 사물에 대해 생각하는 방법이 있습니다. 절차 적 언어의 데이터 구조에 대해 생각해보십시오. 동작이없는 필드 그룹입니다. 이러한 데이터 구조에 대한 포인터를 수신하고 후자를 조작하는 함수에 대해 생각해보십시오. 이제 분리하는 대신 구조 정의 내에서 함수를 정의하고 함수가 일반적으로 조작 할 데이터 구조에 대한 포인터를받는다고 가정합니다. 그 포인터를 이것을 호출합니다. 요약하면 객체를 상태 (데이터)와 동작 (방법-OOP의 기능에 대한 멋진 이름)의 조합으로 생각하십시오.

이것이 절대적인 기본입니다. 반드시 숙달해야하는 세 가지 개념이 더 있습니다.

상속-이것은 코드 재사용에 관한 것입니다.

캡슐화-이것은 인터페이스에서 구현을 숨기는 것입니다. 간단히 말해, 달리 입증 될 때까지 모든 것이 비공개 여야합니다.

다형성-참조 변수의 유형이 아니라 실제 인스턴스의 유형이 어떤 동작 (메소드)이 호출되는지 아는 것은 중요합니다. Java는 정의상 모든 것이 다형성이기 때문에이 개념을 쉽게 볼 수 있도록 만들지 않습니다. .Net을 사용하면 다형성과 그렇지 않은 것을 결정할 때 더 쉽게 이해할 수 있으므로 행동의 차이를 알 수 있습니다. 이것은 가상과 재정의의 조합에 의해 달성됩니다.

이러한 개념을 잘 이해하면 괜찮을 것입니다.

마지막 팁 : 최고의 책을 언급합니다. Bruce Eckel의 " Thinking in Java " 를 읽었 습니까? OOP 개념이 명확하게 설명되어 있으므로 .Net을 시작하는 사람들에게도이 책을 추천합니다.

더 민첩 해지고 junit 테스트를 배우고 Domain Driven Design에 대해 공부하십시오. 도메인 중심 디자인 : 소프트웨어 중심의 복잡성 해결 책을 제안합니다 .

OOP 기술은 시간이 지남에 따라 제공됩니다. 1, 2 ... 10 권의 책을 읽는 것은 그것을 자르지 않습니다. 코드 작성을 연습하십시오. 프로그래밍 환경에서 작업하는 경우 도움이 될 수 있습니다. 하나에 들어 가지 않으면. 일부 애플리케이션을 무료로 개발하도록 제안하십시오. 손을 더럽혀 야합니다. 처음부터 완벽한 애플리케이션은 없습니다. 그래서 리팩토링이 필요합니다.

또한 ... OOP에 너무 많이 몰두하지 마세요 ... 시간이 지남에 따라 일부입니다. 완전한 기능의 애플리케이션 개발에 대해 걱정하십시오.

가장 순수한 OO 언어 중 하나 인 Self로 프로그래밍을 시도해보십시오 . 사실 너무 순수해서 클래스도없고 객체 만 있습니다. 또한 변수, 필드, 정적, 속성이없고 메서드 만 있습니다. 또한 흥미로운 사실은 시스템의 모든 개체가 화면의 개체이기도하고 그 반대의 경우도 마찬가지라는 사실입니다.

Self에 대한 흥미로운 논문 중 일부는 SELF 4.0을 사용한 프로토 타입 기반 애플리케이션 구성 (자체 자습서), Self : The Power of Simplicity 및 Organizing Programs Without Classes 입니다. 또한 Self : The Video (Randall B. Smith; Dave Ungar) 는 언어의 디자이너 중 두 명이 Self의 아이디어를 설명하는 멋진 작품 입니다.

이것은 거의 모든 개념에서 작동합니다. 실제로 적어도 저에게는 : 배우고 싶은 개념을 가장 순수하게 구현하는 언어를 찾아서 사용하십시오.

OO는 거래를 처리하고이자를 계산하고 모든 것을 추적하는 은행과 같은 프로그램을 프로그래밍하려고 시도한 후 마침내 나를 클릭했습니다. Java를 배우는 동안 그렇게했습니다. 시도해보고 완료 한 다음, 완료되면 GOOD 솔루션을 살펴보고 더 잘할 수 있었던 것을 확인하는 것이 좋습니다.

나는 또한 OOP 기술이 주로 연습을 통해 강화되었다고 생각합니다. 3 년 이상 근무한 경우 회사 변경을 고려하십시오. 확실히 이것은 모든 직업에 유효하지는 않지만 종종 한 남자가 회사의 프로젝트와 관행에 익숙해지고 시간이 지남에 따라 발전을 멈 춥니 다.

소매와 코드를 감아보세요!

당신은 스스로 대답했다 : 연습하라. 이를위한 최선의 해결책은 게임을 개발하는 것입니다. 그곳의 책에서 배운 개념을 사용하십시오.

Scott Meyers "Effective C ++"책의 초판에서 OO에 대한 장을 읽었습니까? 이후 버전에는 적용되지 않았지만 훌륭한 설명이었습니다. 제목은 기본적으로 적절한 관례에 대해 "당신이 말하는 것을 말하고, 당신이 말하는 것을 의미한다"였습니다.

실제로 여기 에서 비슷한 질문에 대한 제 답변을보고 싶을 것 입니다.

HTH

건배,

계획을 세우십시오. 객체가 서로 어떻게 관련되기를 원하는지 스스로에게 물어보고 어떻게 변경하고 모듈화 할 수 있는지 알아보십시오.

코드 1 개를 변경하려는 경우 50 개의 인스턴스가 아닌 1 개 코드 만 변경하면됩니다.

OOP는 수천 권의 책을 읽음으로써 마스터 할 수있는 것이 아닙니다. 오히려 내면의 개념을 느껴야합니다. 무엇이든 읽으면서 읽은 것을 느껴보십시오. 머릿속에 개념을 구축하고 새로운 시나리오에 직면했을 때 그 개념을 일치 시키십시오. 새로운 것을 탐색하면서 개념을 확인하고 업데이트하십시오.

행운을 빕니다!

맥주가 도움이됩니다. 진지하게. A3 크기의 낙서 패드, 펜, 맥주를 들고 소파에 눕습니다. 개, 고양이, 아내를 밖에 가두십시오. 긴장을 풀면서 문제에 대해 생각하십시오. 감히 API를 그리지 마십시오!

순서도, 반응 카드 (CRC) 및 맥주 (너무 많지는 않음)는 먼 길을갑니다.

코드를 리팩토링하는 가장 쉬운 방법은 처음부터 그럴 필요가없는 것입니다.

http://misko.hevery.com/code-reviewers-guide/

이 작은 간단한 규칙은 당신을 더 나은 OO 프로그래머로 만들 것입니다. 코드를 작성할 때 규칙을 종교적으로 따르면 코드가 다른 것보다 낫다는 것을 알게 될 것입니다.

또한 Solid Principles를 배우고 싶을 것입니다. http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

이러한 원칙과 프로그래밍 방식이 논쟁을 불러 일으키는만큼 훌륭한 코드를 진정으로 작성하는 유일한 방법입니다.

이미 이런 식으로 코드를 작성했지만 모를 수도 있습니다. 그렇다면 훌륭합니다. 하지만 목표를 향해 노력해야한다면 이것이 바로 황금 표준입니다.

포기 해! 왜 그 OOP가 필요합니까? 사용 가능한 앱을 작성하십시오. OOP, 절차 적 또는 기능적 접근 방식을 사용하여 측정하지 않습니다.

Python 언어를 선택하는 방식은 연습하기에 적합해야합니다.

당신은 내 타겟 청중입니다. OO 디자인의 건축 기술 살펴보기

아마도 이것이 도움이 될 수 있습니다.