I'm learning how to program in Java and I know that most powerful thing in Java is OOP, not writing everything using one class with hundreds of "if()". And as I try to learn, I see that learning new techniques is quite easy, while object oriented thinking and designing of programs is difficult.
Unfortunately, all online courses and books I saw are designed to teach TECHNIQUES. Different behaviours or functionalities of Java with short example programs that demonstrate well what is inheritance or something else.
I can't find examples of well designed but quite simple programs that use multiple various objects that do everything, and one main class that contains only a few instructions to manipulate those objects.
If I understand correctly, this is a well designed application - a problem was solved by designing a few objects in a smart way and operating them. By analysing examples you see that one object may be designed more towards containing some methods, other is ore data-oriented, and you see how can you write programs by thinking objects. The sources I found mostly contain simple programs with one or two objects! How can you learn OOP with these?
Can you help me with some good sources?
Because I am completely beginner, maybe some examples without exact code, just some schemes illustrating how can you solve various problems using objects in a smart way?
Unfortunately, this page www.exampledepot.com/ doesn't work, so I can't say if it contains anything useful.
Personally, I have learnt a lot by learning
a) Design patterns b) Downloading sources from Open source projects and debugging through them
I like to make an analogy with learning how to cook. When you start cooking, you first learn the basic concepts:- what are the various kind of ingredients, what are the different kind of flavors, what are the various kind of textures, etc, etc. This is the core knowledge you need to have before you start learning anything else. This is similar to learning OOP concepts. Then, you learn the techniques:- how do you saute, how do you fry, how do you cut, how do you clean. To me, this is analogous to learning design patterns. Once, you learn the techniques, not only do you learn the technique, but you also start building a common vocabulary that someone can instruct you in. This leads to you being able to follow concise recipes. SO, for example, if you know how to dice a vegetable and you see a recipe that says "Dice an onion", you know what to do. You don't need anyone to explain to you at great length how to hold the knife and the vegetable, and where to cut. Similarily when you learn a design pattern (and UML which is the language that design patterns are expressed in ), you learn a completely new vocabulary. A architect/senior dev can come and tell you "Implement a factory there and a proxy here" and you are good to go. Sure, you can apply OOP without design patterns, just like you can cook without recipes. You just make it harder for yourself
Now, once you start using patterns... and this part takes years of experience.... you start seeing patterns behind the patterns. You become better and better at seeing how well patterns work at solving certain kind of problems. This is very similar to how cooks start building their own style. Once you have followed recipes for a long time, you start figuring out how different techniques blend together. Or you read other people's recipes and you can start imagining how they will work together, just because those techniques are so burned into your brain that you don't have to actually cook to know what something might taste like (although you might just do it for the fun of it). This is the point where you can start making design decisions. It take a lot of time, and it takes a lot of learning, and you never really stop learning this part, ALso, when you get to this point, you gain to learn a lot from watching other masters at their craft. You learn a lot by looking at the design of other applications, and evaluating how they make it work. You can spend a lifetime doing this and you will never get perfection. This is also why Chefs and Architects make the big bucks :p
Jayesh A Lalwani wrote:Personally, I have learnt a lot by learning
a) Design patterns
b) Downloading sources from Open source projects and debugging through them
You don't need anyone to explain to you at great length how to hold the knife and the vegetable, and where to cut. Similarily when you learn a design pattern (and UML which is the language that design patterns are expressed in ), you learn a completely new vocabulary. A architect/senior dev can come and tell you "Implement a factory there and a proxy here" and you are good to go. Sure, you can apply OOP without design patterns, just like you can cook without recipes. You just make it harder for yourself
Now, once you start using patterns... and this part takes years of experience.... you start seeing patterns behind the patterns. ... This is also why Chefs and Architects make the big bucks :p
thank you for taking the time to help us beginners. I am learning Java as well. I know some techniques, like the OP said, but what I really need to know is OOP and other programming patterns. I'm sure there are many great resources on the net regarding learning patterns. I want to practice using them as well, since I learn best by doing. Do you have any resources you recommend using Jayesh?
Jayesh, what way do you use to determine and understand the design patterns used by others in their code?
THere are plenty of resources on the internet that tell you what a pattern is, what the intent behind it is, and what the pros and cons of using it are. However, I don't know of any resources that will tell you how to recognize patterns in already existing code. Good people usually name/document their classes so it's clear what pattern they have used. For example, the listeners in Swing follow the Listener pattern. The creators of Java made it easy for us to recognize by just calling them listeners. However, you might find some people calling them Notifiers, or MessageRecievers, or something like that.
Teasing out patterns from existing code takes practice. It's kind of being a detective. You have to look for clues. You have to reverse engineer the design. It does make reading other people's code easier once you recognize the pattern hey have used. However, reverse engineering is a skill that you don't learn from a book. Don't get disheartened though. Since the GoF published their patterns, it has been widely adopted, and a lot of people have been using the terms used by GoF, and more often than not, the classes are named according to the pattern they are built on. It makes it a lot easier to have industry standard terms.