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

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

---

저는 수년 동안 객체 지향 언어로 프로그래밍 해 왔지만 동료들이 부러워하는 일을 비밀리에 살펴 봅니다. 많은 사람들이 내가 아무리 노력해도 내가 가지고 있지 않은 내면의 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.

        }
    }

---

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

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

Then when you need to be able to execute particular actions (for example, marking a model of car as decommissioned) or ask particular questions (for example, asking how many of a given model of car were sold in a given year), you load that functionality onto the class it interacts with most heavily.

In general, there should always be a pretty natural place for a given bit of code to live in your class structure. If there isn't, that signals that there's a place where the structure needs to be built out.

---

There's too much information about objects. The most important thing is to master the basics and everything falls into place more easily.

Here's a way to think about objects. Think about data structures in procedural languages. They are a group of fields without behaviour. Think about functions that receive pointers to those data structures and manipulate the latter. Now, instead of having them separate, define the functions inside the definition of the the structures and assume the functions usually receive a pointer to the data structure to manipulate. That pointer is called this. In sum, think about objects as the combination of status (data) and behaviour (methods - the fancy name for functions in OOP).

This is the absolute basic. There are three more concepts you must absolutely master:

Inheritance - This is all about code reuse.

Encapsulation - This is all about hiding the implementation from the interface. Simply put, everything ought to be private until proven otherwise.

Polymorphism - It doesn't matter the type of the reference variable, but the type of the actual instance to know which behaviour (method) is called. Java doesn't make it easy to have this concept very visible because by definition everything is polymorphic. .Net makes it easier to understand as you decide what is polymorphic and what is not, hence noticing the difference in behaviour. This is achieved by the combination of virtual and override.

If these concepts are very well understood, you'll be fine.

One last final tip: You mention the best books. Have you read "Thinking in Java" by Bruce Eckel? I recommend this book even to people who are beginning in .Net, as the OOP concepts are clearly laid out.

---

Become more agile, learn junit testing and study about Domain Driven Design. I suggest the book Domain-Driven Design: Tackling Complexity in the Heart of Software although it's a bit tough at some points.

---

OOP skills comes over time. Reading 1, 2 ...10 books doesn't cut it. Practice writing some code. If you are working in a programming enviornment...that can be helpful. If not try getting into one. Offer to develop some application(s) for free. You have to get your hands dirty. Remember...no application is perfect from the ground up.That's why there is re-factoring.

Also...don't get carried away with the OOP too much...it somes over time. Worry about developing fully functional applications.

---

Try some programming in Self, one of the most pure OO languages around. So pure, in fact, that it doesn't even have classes, only objects. It also doesn't have variables, fields, statics, attributes, only methods. Also interesting is the fact that every object in the system is also an object on the screen and vice-versa.

Some of the interesting papers on Self are Prototype-Based Application Construction Using SELF 4.0 (the Self tutorial), Self: The Power of Simplicity and Organizing Programs Without Classes. Also, Self: The Video (Randall B. Smith; Dave Ungar) is terrific, having two of the language's designers explain Self's ideas.

This works for pretty much any concept, actually, at least for me: find the language which most purely embodies the concept you want to learn about and just use it.

---

OO finally clicked for me after I tried to program a bank-like program that handled transactions, calculated interest, and kept track of it all. I did it while I was learning Java. I would suggest just trying it, completing it, and then when you're done go look at a GOOD solution and see what you could've done better.

---

I also think OOP skills strenghten mostly with practice. Consider changing your company, if you've been there for more than 3 years. Certainly, this is not valid for all jobs, but often a man gets used to the projects and practices at a company and stops advancing as time passes.

---

You said the answer yourself: practice. Best solution for this is to develop a game. Use the concepts you learnt in the books there.

---

Have you read the chapter on OO from the first edition of Scott Meyers "Effective C++" book? It didn't make it to later editions, but it was a great explanation. The title was basically "say what you mean, mean what you say" about suitable conventions.

Actually, you might like to see my answer to a similar question over here.

HTH

cheers,

---

Roll up your sleeves and code!

---

Plan things out. Ask yourself how you want your objects to relate to eachother and seek out how things can be changed and modularized.

Code things in such a way that if you wanted to change 1 piece of the code, you only have to change that 1 piece of code and not 50 instances of it.

---

OOP is not a thing you can master by reading thousands of books. Rather you have to feel the inner concepts. Read anything but try to feel what you read. Build a concept in the back of your mind and try to match those concepts when you face a new scenario. Verify and Update your concepts as you explore new things.

Good luck!

---

beer helps. seriously. lie out on a couch with an A3 sized scribble pad, a pen and a beer. Lock the dog, cat and wife outside. And think about the problem while relaxed. Don't even dare draw an API on it!

Flowcharts, Responsibity cards (CRC) and beer (but not too much) go a long way.

Easiest way to refactor code is to not have to in the first place.

---

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

Those small simple rules will make you a better OO programmer. Follow the rules religiously as you code and you will find your code is better than it would otherwise be.

You'll also want to learn the Solid Principles: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

As much as these principles and ways of programming cause debate, they are the only way to truly write excellent code.

You may already write code this way and not know it-- if so, great. But if you need a goal to strive towards, these are the gold standard.

---

Give up! Why do you need that that OOP? Just write some usable app. Doesnt metter using OOP, procedual or functional approach.

Whataver approach you choose Python language should be sutable to practice it.

---

You're my target audience. Look at Building Skills in OO Design

Perhaps this can help.

참고URL : https://stackoverflow.com/questions/1301606/how-can-i-practice-better-object-oriented-programming