Any Tips for Understanding OOP?

Question

At this point I can no longer recall how many intermediate programming courses I've completed that teach the basics of classes: inheritance, properties/methods, getters/setters, polymorphism, constructors/destructors, etc. But what I'm finding much harder than learning the syntax is how to actually put these ideas to use in real code, which seems like the real art form in OOP. I've seen a million examples of Cat classes extending the Animal parent class with an overloaded method, and Car classes that have color, weight, and speed properties with Accelerate() and Stop() methods. But this isn't enough to help me employ OO patterns when solving problems with programming. Every time I try to level up my programming skills from "scripter who only writes a bunch of statements, functions, loops and conditions" to "programmer who follows a thoughtful/logical design pattern that other developers can understand and build on top of" I become paralyzed by not knowing how to fit the idea of my program into an object oriented model. As much as I love him, I'm realizing that watching another Derek Banas video isn't what I need right now. Does anyone have some tips for "thinking in objects"? Something that will help this paradigm click and help answer the following questions? I'm not sure how much this matters but I am learning primarily in Python (although I've explored this topic with other languages too).- How do I decide what parts of my program should be based on classes?- Is it possible to go OO crazy and needlessly complicate the program? How do I KISS?- Are there any tools or resources that can help model a program from the onset using an OO design pattern?- Can I write a serious program without OO or should I resign myself to staying in script kiddie land until I learn it properly?- Should I look into another paradigm? Is my only other choice to use a functional langauge like F# or Clojure?

jqpabc123 · Accepted Answer

The idea behind OOP is to simulate real world objects. One of the first OOP languages was called Simula.
But this simulation concept is not particularly well adapted to the world of business and information technology. Business is highly data driven and most business objects are defined as data. The objective of business software is typically to process input data (lots of it) and produce output data. There is little real world evidence to show that this can be done easier, faster or more efficiently using OOP.
In my opinion, unless you're creating a real world simulation of some sort that will exist entirely within computer memory, binding data and code together offers little practical, real advantage. When it comes time to communicate or store business data, the OOP code/data binding actually becomes more of a hinderance.
This is not to say that OOP is not useful. It's no surprise that one of the most popular applications of OOP is building graphical user interfaces --- an on-screen simulation of a paper data form that is built and exists entirely within computer memory.
Applying OOP to problem spaces where it is not well suited often results in slower, more complex, harder to maintain applications. Instead of spaghetti code, OOP programmers all too often tend to create spaghetti objects that obfuscate more than enlighten.

noduerme · Answer

You can certainly write any end product without OOP as you could with it. I happen to like OOP because I think more visually and geometrically than linearly. My answer to your question about how to write clear code that maximizes OOP's usefulness is to constantly consider what attributes in subclasses you can or should push up the inheritance chain. For example, I spent a long time working on a piece of software that had pop questions, quizzes, and tests separated into different kinds of objects and database structures. Getting familiar with the commonalities and differences between these user interactions, I was able to restructure the code so that tests extended quizzes, which were a collection of questions paired with answers and users. Maybe this should have seemed obvious to the original coder, but when things grow organically you don't always design them in the ideal way. Restructuring that helped me migrate the database to a simpler, cleaner set of connecting tables that then helped expose a lot of data (user performance) that was much harder to tease out previously. So to me, OOP is more a way of getting at the truth of business / application logic. When trying to solve a small problem, I often write functional inline code. But on a large scale I use objects to clarify the relationships between real world artifacts.

quickthrower2 · Answer

I use c# and will usually create a class where it makes sense for there to be a “state” managed by a bunch of methods. Where you don’t want anyone outside directly playing with that state.
I very rarely use inheritance. I can’t remember the last time I added inheritance but I sometimes come across it in code bases. Normally when there are something resembling UI widgets that have a common base.
Instead I use c# interfaces for polymorphism (which basically means working with objects you don’t know what they are, e.g. I have something that behaves like a list, so i can call addItem() )
My first advice is don’t worry - if your code works and is understandable all is good.
My second advice is post your code for code review, or get a mentor or coach to help show you if and how your code could be better with OO
Functional programming avoids the need for OO but comes with its own “what is the best way to do this” type questions to which I give the same advice.

lastofus · Answer

"99 Bottles of OOP" by Sandi Metz does a fantastic job IMO of answering the first 3 questions listed.
> Can I write a serious program without OO...
Absolutely! See any program written in a functional only language, or C.
> Should I look into another paradigm?
Eventually... I'm personally a huge fan of Clojure. That said, don't give up on OOP. It's pretty unavoidable in industry.

drost · Answer

I would read "Refactoring" by Martin Fowler, if you haven't already. It will help you understand what OO code should look like and give you the tools to help get you there.