I'm newbie of C# developer. I have a little knowledge of C# and OOP. My goal in this year is "To be master in programming and object oriented technology" I have set my learning path as follow. (order by learning step)
Is my learning path is good? If not please suggest me for better path.
Thanks
Honestly if the steps are in any order, I would move UML to the bottom of the list. And study up on TDD and DDD for your design patterns.
You won't be much of a master of OOP without Design Patterns, those two go hand in hand so I'd move it up. Good luck!
Its impossible to become a "master" in 1 year. I've been programming C# for 4 years (working as a engineer too) and I'm still not a 'master'. As as matter of fact, no one really is a 'master' programmer.
there is no linear path (unfortunately) but your list isn't bad.
Maybe add
I really like the book "Beginning algorithms", it will help you understand the inner workings of classes/apis you will use in almost every language. Also, never overlook administrative tasks, if you have time and a couple bucks, set up a Linux EC2 instance. Then set up Apache with Tomcat, MySql and mod_jk. Test and make sure you can hit your Tomcat app from your home pc. You can set up a simple Struts app using Maven, which will help you learn about the build and deployment strategies and dependency management... Especially transitive dependencies. It may sound easy, but it is a learning experience.
You should study Design Patterns and Architectural Patterns. For Design Patterns I would recommend the book Head First Design Patterns and the site dofactory.
I would also recommend reading up on Domain Driven Design, which will help you with requirements as well as good overall OOP/OOAD. You should also learn the SOLID principles. TDD would not hurt either
UML is not that important. Learning Use Cases would be a more important skill. UML is more of a Waterfall type skill. I would study up on Scrum and XP instead.
Study whatever in whichever order. The only real way to become a "master" is to write programs. Preferably in a situation where you have peers who can review your code.
OO takes a while to figure out. Just when you think you've 'got it', you discover that you've been programming procedurally all the while.
Anyway, I would say learn C# first, then concentrate on design patters (but don't go over the top). Also, learn the design principles that the patterns are based upon:
However, as others have noted, the only way to master the concepts is to practice and make a lot of mistakes. The first one you will make is slavishly following the principles, which will create a huge abstracted mess. You need the knowledge as well as the experience to know when to use the wonderful new skills.
Practice should be your #1 item. Every once in a while, go have a look at some design patterns book, which will make much more sense anyway once you've encountered the problems those patterns try to solve.
One year won't be enough, however.
To be thorough in C# and to know the advancements of the language from version 1 to 2 and to 3, I suggest you read C# in Depth by Jon Skeet. The book is published by Manning and when you buy the book, you get a free e-Book copy (PDF) as well.
Suggest you buy from Amazon where its much cheaper.
It is not the case that you will learn those different items in a set order, rather they are all interrelated. You can't fully learn one without the other. As you learn C# you'll learn OOP. And as you learn OOP you'll be exposed to UML and design patterns.
With regards to OOP the best book I've read was Betrand Meyer's OOP Software Construction book. This book looks at how one would go about building a language to handle the various different OOP constructs that one would want in a programming language. It is no where near as heavy as it sounds. After reading this you will have properly learned (at least in theory anyway) how to 'think OO'.
Now you can learn as much theory as you want, and you can even gain some real-world experiience, but until you've really battled on a number of small and large projects, facing lots of different problems, then you can't even consider yourself "experienced". To become a master? More passion and time and geunine entusiasm than most of us have along with a natural talent for programming + about 20 years experience ;)
Malcolm Gladwell (in his recent book Outliers) cites the "10,000 Hour Rule": in any field of artisanship, it takes about 10,000 hours of work to attain mastery. This is true of goldsmithing, surgery, and playing the violin; it's certainly true of programming. Given that most programmers spend about half their time doing things that aren't programming, you should expect attaining mastery to take about 10 years, and that's assuming that you have a productive apprenticeship (i.e. work under a master who teaches you what to do). Most programmers don't, and that can make it take more like 20 years.
It will depend on your learning type, but I have found that in my situation, I learned best by looking at other people's code and refactoring it.
Do yourself a big favor and get the bible on Refactoring by Martin Fowler and utilize the Refactoring patterns found in that book. By looking at other's code and improving it, many times you learn the lessons you really need to learn without getting frustrated by syntactical errors and the like.
Then, do yourself another favor and start developing the right way to begin with. Related to DDD, definitely look at Test-Driven Design/Development and don't start bad habits of writing untestable code. It takes far longer to break bad habits than to learn proper habits.
And, when you get to a point that you don't enjoy it, step out of it for awhile, be it 2 minutes, 2 hours, 2 days or 2 years. If you're developing and you're mad about it, your code will royally suck. Ask me how I know. :)