Learning to think in the Object Oriented Way

Question

I've been doing software development with OO for over 20 years now, and I can tell you that looking at other peoples code is more often than not going to teach you how to do procedural programming in an object oriented language.

What I would recommend is to use the following techniques, which if applied liberally, will force you to use OO techniques, even though you may not yet be aware of them.

1. Do not copy and paste code - ever.
2. Create classes that represent the things you talk about when talking about the functionality - for example, an order entry system will have Orders, Customers, Accounts, OrderItems, InventoryItems, etc.
3. When creating these classes, do NOT code any public set and get methods to access the class data members.
4. Add methods to these domain model classes that perform the work on the object in question. Order.invoice(), account.close(), InventoryItem.decrement(). The lack of public get methods will show you the correct location for the code (where the data is - in the appropriate domain object). Remember, an object is data and the code that operates on it - anything short of both is not an object.
5. You will eventually find that you have to add some public get methods for some class members, and that is ok, just hold off until you are forced to do so. Reluctantly add public get methods.
6. At the level of the application, almost every line of code should be moving mountains. In other words, most of the lines of code at the application level should be calling on domain model methods.
7. Put all of the functionality in the domain model objects, then expose that functionality in an application by hooking it up to a user interface. I repeat, put the functionality in the domain model, not the application.

If you follow these guidelines, you will definitely be producing object oriented code, and probably at a much higher level of proficiency than many experienced developers.

Finally, avoid injection - i.e. Spring, Unity, etc!! There are probably a handful of valid cases for using injection - most uses arise out of a lack of object oriented design experience. As a guideline for whether to inject or not, consider how often what you are thinking of injecting is likely to change. In many, many cases, I find that what is being injected will never change - in these cases, the only thing being injected is pure overhead.

Good luck!

1. Read other people's code - people who you know are good developers
2. Books/articles that teach "idomatic usage" of the language
3. (Avoid anything with the words "in 21 days")

It takes time.

Moving from procedural programming to object oriented is difficult. These days, many people start with object oriented, so they don't struggle with this paradigm change.

• Learn about the fundamentals of OOP and keep referring to them to start with.
• Read OO code - there are lots of open source projects out there that you could sample.

read one of the following book

1. 2015_Book_Object-OrientedAnalysisDesignA
2. Head First Design Patterns By Eric Freeman and Elisabeth Freeman Small
3. Head First Object-Oriented Analysis and Design: A Brain Friendly Guide to OOA&D

enjoy

PDF LINKS

1) Head First Object-Oriented Analysis and Design

Head First Object-Oriented Analysis and Design.pdf

2) Head First Design Patterns

Head First Design Patterns.pdf