How can I better practice object oriented programming?

Question

I have been programming in object-oriented languages ​​for many years, but secretly I look at some things that my colleagues do with envy. Many of them seem to have an internal OO instinct that I don't have - no matter how hard I try. I have read all the good books on OO, but still can't hack them. I feel like a guy who gave 110% to be a professional football player, but he did not have natural talent. I am at a loss and thinking about switching professions - what should I do?

Answer 1

I would say that I no longer focus on OO programming and focus more on OO design. Take paper and pencil (or perhaps a UML modeling tool), and leave the screen.

By practicing how to develop a system, you will begin to feel the natural relationship with objects. Code is just a byproduct of design. Draw diagrams and model your application in a purely non-code form. What is the relationship? How do your models interact? Don’t even think about code.

Once you have spent time designing ... then translate it into code. You will be surprised at how quickly code can be written with a good OO design.

After much design practice, you will begin to see common areas that can be modulated or abstracted, and you will see an improvement in both your projects and your code.

Answer 2

The easiest way is to learn concepts such as SOLID, DRY, FIT, DDD, TDD, MVC, etc. When you look at these acronyms, it will lead you to a lot of other rabbit holes, and as soon as you finish reading, you should be well aware that object-oriented programming is better!

SOLID podcasts: http://www.hanselminutes.com/default.aspx?showID=168 , http://www.hanselminutes.com/default.aspx?showID=163

SOLID breakdown: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

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

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

DDD: http://dddcommunity.org/

DDD reading required: 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

And yes, sleeve folding and coding is always a good idea. Make a small project to the best of your abilities. Then read the article above. Then reorganize your code to fit the needs of what you just read. Repeat until you reconfigure hell from your code. In the end, you should not only know what OO is, but you should be able to explain why it is important and how to get them for the first time. Learning how refactoring is key to good code too. What is now right now, not tomorrow.

Answer 3

My suggestion would be to learn something else.

Learn functional programming and apply what you learn from this to OOP. If you know C ++, play around with general programming.

Learn non-object oriented languages.

Not only because you have to use all these things (you should), or because they should completely replace OOP (they probably shouldn't), but because you can also apply the lessons from them to OOP.

The secret of OOP is that it does not always make sense to use it. Not everything is class. Not every relationship or part of the behavior should be modeled as a class.

Blindly trying to apply OOP or striving to write better OOP code, as a rule, it leads to huge overloaded riots with too many levels of abstraction and indirectness and very little flexibility.

Do not try to write good OOP code. Try writing good code. And use OOP when it contributes to this goal.

Answer 4

In many fields there is a "eureka" where everything happens together.

I remember the feeling of disappointment in high school geometry. I did not know which theorem to apply at each step of the proof. But I continued to do it. I studied each theorem in detail and studied how they were applied in different examples. Since I understood not only the definition of each theorem, but also how to use it, I created a “toolbox” of familiar methods that I could pull out as needed.

I think the same is in programming. That is why algorithms, data structures, and design patterns are studied and analyzed. It is not enough to read a book and get an abstract definition of technology. You should also see this in action.

So, try reading more code , in addition to the practice of writing it yourself. This beauty is open source, you can download a lot of code to study. Not all of this code is good, but learning bad code can be as educational as learning good code.

Answer 5

Too many people think about coding first, objects last.

You can read all the books you want, but you are not going to teach you to think in an object-oriented way - this requires practice and a certain methodology.

• Here are a few methods that helped me: when you are away from working and discovering, you can , considering everything as an object . Do not look at these objects and it is interesting how you are going to program them, look at them as soon as the properties and functions are related or inherited from each other. For example, when you see a person, they are an object and therefore will represent the class. They have properties such as hair color, skin tone, height, etc. They perform certain functions. They walk, talk, sleep, etc. Some of the functions that people return are Results. For example, their working function returns the amount in dollars. You can do this with everything that you are because everything is an object. Bicycle, car, star, etc.

• Before you encode a project using post notes and dry erase. It will do good practice until you get it. Think about your specific object / function / property. Each of these items will have their own post-it note. Place them as hierarchies on a dry-erased board. In this regard, the function / properties will be placed under the object. If you have another object, do the same for this. Then ask yourself, make any of these messages it notes (objects / function / property) related to each other. If two objects use the same function, create a parent object (post-it note) and put it higher than the others with the reusable function under the new note. Draw a line using a dry erase marker from two children of the objects to the parent.

• When all this is done, about the internal aspects of how the class works.

Answer 6

Learn another language! Most developers using only Java (as an example) have a limited understanding of OO because they cannot separate language functions and concepts. If you don't already know this, look at python. If you know python, learn Ruby. Or select one of the functional languages.

Answer 7

The question is in your question;)

Practice, practice, practice.

View your own code and find out about errors.

Answer 8

TDD has helped me the most in improving my overall skill set, including OOP.

Answer 9

The more code you write, the more you will notice the pitfalls of certain programming methods. After enough time and enough code, you can identify the warning signs of these traps and be able to avoid them. Sometimes, when I write code, I get this itch at heart, telling me that there may be a better way to do this, although it does what I need. One of my biggest flaws in programming is “over-analyzing" things so much that it starts to drastically slow down development time. I try to prevent these "itches" by spending a little more time on the design, which usually leads to a significant reduction in the time it takes to write the code.

... secretly, I look at some things that my colleagues do with envy. Many of them seem to have an OO internal instinct that I don’t have - no matter how hard I try ...

I think you answered your question here. Reading good code is a good start, and understanding good code is even better, but understanding the steps to get to this good code is best. When you see some code for which you are jealous, perhaps you could ask the author how he came to this decision. It completely depends on your work environment, as well as the relationship with your colleagues. In any case, if someone asks me about the thought process for any code that I write, I feel free to tell them, because I know that I would like them to do the same for me.

Answer 10

Language designers have interpreted "object-oriented programming" in different ways. For example, see how Alan Kay, the first person to use the term OOP, defined it:

OOP for me means only messaging, local save and protect and state process and extreme late binding of all things. Can be done in Smalltalk and in LISP. There may be other systems in which this is possible, but I do not know them.

(Quote from http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en ).

It may seem strange that he does not consider programming languages ​​in Java and C ++! But, as a developer of one of the first and best OOP languages ​​(Smalltalk), he has his own good reasons for this. Why did Alan Kay consider Lisp an object-oriented language, but not Java? This issue requires serious consideration by all who claim to understand OOP.

Erlang has various OOP functions , the circuit has a different one. It is worth considering all these alternative views. If possible, learn all these languages! This will give you a wider overview, add new and powerful tools to your hands and make you a better programmer.

I summarized my experiments with the implementation of the OOP language based on ideas borrowed from Smalltalk, Scheme, and Erlang in this article .

Answer 11

If you lose the idea of ​​creating object-oriented systems, start with the data. Find out what things you need to track and what information naturally goes together (for example, all the characteristics of a model group of cars together are beautiful).

Each of these types of things that you decide to track becomes a class.

Then, when you need to perform certain actions (for example, mark a car model as decommissioned) or ask specific questions (for example, ask how much this car model was sold for a certain year), you load this functionality into the class with which it interacts most actively.

In general, there should always be a pretty natural place for this bit of code to live in your class structure. If this does not happen, it means that there is a place where the structure should be built.

Answer 12

Too much information about objects. The most important thing is to master the basics, and everything becomes easier.

Here is a way to think about objects. Think of data structures in procedural languages. They are a group of fields with no behavior. Think about the functions that get pointers to these data structures and manipulate the latter. Now, instead of separating them, define functions within the definition of structures and assume that functions usually get a pointer to a data structure to control. This pointer is called this. In general, think of objects as a combination of state (data) and behavior (methods are a fancy name for functions in OOP).

This is an absolute basis. There are three more concepts that you must fully master:

Inheritance - all this relates to code reuse.

Encapsulation is all about hiding the implementation from the interface. Simply put, everything should be private until the opposite is proved.

Polymorphism. The type of the reference variable does not matter, but the type of the actual instance to find out what behavior (method) is being called. Java does not make it easy to understand this concept, because by definition everything is polymorphic .. Net makes it easier to understand when you decide what is polymorphic and what is not, therefore, noting the difference in behavior. This is achieved by a combination of virtual and redefinition.

If these concepts are well understood, you will be fine.

Last final tip: you mentioned the best books. Have you read Bruce Eckel's Thinking in Java ? I recommend this book even to people who start on .Net, as the concepts of OOP are clearly marked.

Answer 13

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. } } 

Answer 14

Become more flexible, learn how to test Junit and learn Driven Design. I offer the book Development under the control of the domain: the struggle with complexity at the heart of software , although in some cases it is a bit complicated.

Answer 15

OOP skills come with time. Reading 1, 2 ... 10 books does not cut. Code writing practice. If you work in a programming environment ... this may be useful. If you do not try to get into one. Offer to develop application (s) for free. You have to get your hands dirty. Remember that the application is not perfect from scratch. That is why repeated factoring occurs.

Also ... don't get too involved with OOP ... it's over time. Worry about developing fully functional applications.

Answer 16

Try some programming in Self , one of the purest OO languages. So pure, in fact, that he doesn’t even have classes, only objects. It also has no 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 works on the topic “I” A prototype-based design using SELF 4.0 (self-study tutorial), Self: The Power of Simplicity and Organization of programs without classes . Also, Self: The Video (Randall B. Smith, Dave Ungar) is awesome as two language designers explain Self's ideas.

This works for almost any concept, in fact, at least for me: find the language that most purely embodies the concept that you want to learn about, and just use it.

Answer 17

I also believe that OOP skills are mainly related to practice. Think about how to change your company if you have been there for more than 3 years. Of course, this is not suitable for all tasks, but often a person gets used to projects and practice in the company and stops developing over time.

Answer 18

Roll up your sleeves and code!

Answer 19

You yourself answered: practice. The best solution for this is to develop a game. Use the concepts you learned in books.

Answer 20

Plan things. Ask yourself how you want your objects to touch each other, and find out how things can be changed and modularly.

Encode things in such a way that if you want to change one piece of code, you only need to change that piece of code, not 50 instances.

Answer 21

Have you read the chapter on OO from Scott Meyers' first edition of Effective C ++? This did not reach later editions, but it was a great explanation. The title was basically "say what you mean, what you say" about suitable agreements.

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

NTN

amuses

Answer 22

OOP is not something you can master by reading thousands of books. Rather, you should feel the inner concepts. Read something, but try to feel what you are reading. Build a concept in the back of your mind and try to juxtapose these concepts when confronted with a new scenario. Check and update your concepts while learning new things.

Good luck

Answer 23

OO finally clicked on me after I tried to program a banking program that processed transactions, calculated interest and tracked it all. I did this when I was learning Java. I would suggest just trying, completing it, and then when you are done, look at the GOOD solution and see what you could do better.

Answer 24

Beer helps. jokes aside. lying on the sofa with A3 doodle pillow, pen and beer. Block the dog, cat and wife on the street. And think about the problem while it is relaxed. Don't even dare to draw an API!

Flow charts, responsibility cards (CRCs) and beer (but not too many) go a long way.

The easiest way to refactor is not necessarily first.

Answer 25

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

These little simple rules will make you a better OO programmer. Follow the rules as you code, and you will find that your code is better than otherwise.

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

As far as these principles and programming methods are debatable, they are the only way to really write great code.

You can already write code this way and don’t know it - if so, great. But if you need a goal to strive for, this is the gold standard.

Answer 26

You are my target audience. See Building Skills in OO Design

Perhaps this may help.

Answer 27

Give up! Why do you need this OOP? Just write some useful app. Does not affect the use of OOP, procedural or functional approach.

Whatever approach you choose, Python must be spontaneous in order to practice it.