• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Learning object oriented thinking, NOT only techniques

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

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.
 
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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

 
Marshal
Posts: 80230
424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And welcome to the Ranch
 
Ranch Hand
Posts: 112
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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



Jayesh,
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?

I want to be able to know design patterns so well that when a fellow programmer introduces some new JavaScript framework or some new Java service, or in other languages, that I can quickly recognize the design pattern behind the code and its functionality. I feel like if I can know design patterns and know which pattern is being used in a particular app or API then I could learn programming much faster and I could read other programmers' code much faster.

Jayesh, what way do you use to determine and understand the design patterns used by others in their code?
 
Jayesh A Lalwani
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Maybe he went home and went to bed. And took this tiny ad with him:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic