Becoming a good analyzer and designer can greatly benefit a developer. But there are definitely obstacles for this. Not everybody is interested in OOAD, and not every person who is interested, knows the path. Should a good OOAD know multiple OO languages? Or should he/she have failed projects? How can one become a good OOAD?
People who aren't interested are creating their own obstacles. I can't worry about that.
For those who don't know the path, I suggest:
- I find that every OO language I learn makes me a better OO developer. Much can be brought from each language into others, as long as you find the community.
- You do learn more from failure than from success, but try to do that on your own time. Professionally, trust in those with more experience, at least some of the time -- but don't be afraid to ask "Why?".
- Learn all five of the SOLID principles and understand why they exist. None of them are rules, but they are good guidelines when you're lost.
- Test Driven Development made more of an improvement to my OO design skills than anything else I've ever learned.
- You will not be your best until you've gone from underengineering to overengineering and then found the correct balance (closer to the latter).
- Actually, scratch that, you'll never be as good as you will be two years later.
- Read a lot of books and blogs but take nothing as gospel. This industry still hasn't found, and may never find, a perfect path.
- By all means learn design patterns, but don't look for places to use them, simply use them as a facilitator to communication.
Hope some of that helps.
I think that in order to fully appreciate the OO model, you must have experience failing miserably with non-OO programming techniques. You can understand OO inside and out, but to appreciate and respect it, it has to be a shiny new tool that replaces the old rusty one that didn't quite do the job.
I self taught myself for 7 some years before finally learning OO in college level Java. Before that, I would constantly build these projects out, and they would get so big that I would forget what the heck was going on. They would be bulky, unorganized, and require a lot of maintenance to make minor changes. Basically I kept finding myself getting bogged down with my code and starting over fresh constantly.
It took me a while to get my head out of the linear design that I had adopted, but once I fully understood the OO model it was like Eureka! I was able to code much more complex projects on my own and my productivity shot through the roof after learning concepts such as inheritance. I'm not wasting time re-writing code or starting over, because objectively everything makes sense and it just intuitive.
It is my opinion that every programmer should know as many languages as they can. This will make them a more seasoned veteran, regardless if it is OO or not. Once you DO understand OO, you can take those techniques and apply them everywhere they're implemented.
IMHO, if you don't understand, or have no desire to learn OO, you will be inadequately equipped in the battlefield of life. More and more companies are using newer OO languages. I don't see any reason to not know the OO model this day in age.
Depending on how the person learns, it is up to them on how they want to learn the model. I personally learn best when someone teaches me, and so going to class for Java I and Java II really made a big difference for me. I would recommend taking software engineering electives on college, or just simply going online and looking for OO tutorials if you don't have access to college courses or want to learn in your spare time.
When I think back to how it was described to me, I say; an Apple is an Apple, and an Orange is an Orange. Yes, they both fall from trees, but they are two totally different fruits and there lies your harmony.
There are always obstacles for those interested or not but the context and severity may vary.
Its not necessary that you need to learn multiple language for OO concepts, start off with one language which you like, over a period of time you will get a strong foothold on the language, post this its feasible to explore some things which you have done already and try to execute the same on a different language. Expertise in one language helps in switching to new ones since you would have a benchmark to rate.
Any project is a learning experience rather than its success what important is how well have you adapted the features for your best use, occasionally its good to read others code and figuring out how and why its done. If you can get a mentor that would be great. Always know the reason Why this is chosen, How about doing it in some other way. Try to work on your own logic and design model and toss it up to your senior/mentor. This way you would be improving your skills, maybe at the start they would go straight to the dustbin but then you have attempted and learned what you did wrong. Iteratively you would get better and better.