How to get Object Oriented Programming Concepts? [closed]

A class must aim to do one thing and do it well. Nothing else.

There's more to it than that, but that's the main thing. If you go by that you can't go wrong. If your class does too much, it's time to break it apart into smaller pieces.

This is known as the Single Responsibility Principle ^{(emphasis mine)}:

In object-oriented programming, the single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

Note that I am just answering your example. For the rest, your question is too broad. Your best bet to "get" OOP will be to indeed practice OOP. Just:

1. Read a few books.
2. Do some projects to break your teeth on these concepts a few times.
3. Don't try to memorize all these fancy names (including the SRP above).
4. Get your code bashed and reviewed.

It starts at the design phase, before you write any code. Think about what your program is modelling. If its an e-commerce website you might think about Customer, order, product and so on. These nouns become your first objects.

Then you think about what processes need to occur. As an example, when the website takes a new order, there will need to be a point where you take payment for the order. You may define an object as Payment, and this object represents the payment details, and the status of the payment. Now different payment types need processing differently. So you could define a common interface IPaymentProcessor and then create payment processor objects that each only process particular types of payment. e.g PayPalPaymentProcessor and VisaPaymentProcessor.

At this stage, you are starting to write object oriented code...

The Sun/Oracle API, particularly the Javadoc but also the source code itself, provides lots of good examples. You'll use this stuff anyway; when you do, just take a harder look at it than you need to do to get the job done. In particular, JTable is very interesting. It and its associated classes have way too many methods, which muddles it a bit as a learning tool. (I'm becoming convinced that convenience methods are evil.) But note particularly how it uses TableModel. (And also rows, row selection, columns, printing a cell, editing a cell....)

It can take a while to grasp what Sun was doing. OOP tends to be at right angles to everything else; you have to get your brain to think in different ways and then keep it thinking differently.

To try to put OO into two sentences: An object acts as a server, returning information or taking an action upon request. In doing this it can also act as a client and use other servers to do things or return information. (And it can treat, upon request, a client as a server and feed back information on its own schedule and initiative.)

One thing that helped me immensely was Alan Kay's (who practically created the OOP paradigm) email, in which he answered some questions about OOP. Especially this part:

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages

Now, there are no messages per se in most OO-languages (one notable example is C#). But the idea stands: objects are like biological cells.

Some cells generate hormones, others filter blood, etc. This is their specialization. Their inner workings must not be distrubed -- that's why they have cell membranes.

However, they also need to communicate with other cells. This is why they have receptors -- proteins that stick out of membrane and can detect certain chemicals.

For example, when we are in danger, adrenal gland's cells "send" adrenaline to muscle cells. Muscle cells have receptors that "catch" adrenaline, and upon "receiving" it start producing more energy.

So the cells are isolated in their work, but open to communication.

OOP paradigm yearns to compose a program from such cells -- objects.

Objects do their one thing and never allow other objects to interfere with their inner workings (this is why we have private and protected properties and methods). However, they also allow pre-defined ways of communication (this is why we have public methods and properties; also interfaces).

Programming in the OOP paradigm means

1. Coming up with objects which do their one thing and know only what they need to know to do it.

2. Allowing objects to share what they know in an understandable and reliable way.

Why this is important? Because this modularity gives people a better understanding of code. Principles of OOP aim to make sure that you know what's going on at any given moment. If you change one class, you won't affect the system as a whole. If something goes wrong, you can see where the problem is. This allows for flexible and reliable code -- which is usually what real-world businesses need.