3 ms·

Likening objects to things like refrigerators and toasters is where I get lost. Perhaps those examples work well in the classroom to help kids wrap their heads

Likening objects to things like refrigerators and toasters is where I get lost. Perhaps those examples work well in the classroom to help kids wrap their heads around the concept of OO ... I have sometimes thought the same thing. There are ample explanations of the use of OOP put in terms of stuff like, poodle inherits from dog, which inherits from mammal etc. or a car could be represented as a series of objects interacting with each other, the engine, gear box etc. This is all perfectly fine and super easy to visualise. But the stumbling block for me is sometimes when I try to turn these ideas to something that's actually useful. Abstact concepts that indeed do not always have a neat corelation in the real world. If anyone has some tips on how one can begin to develop a clearer method for modeling more abstract concepts in OO, I'd love to hear them.

yters 18y ago
I mainly use it b/c it helps to easily swap out different implementations of a generic object. Useful if I'm coding a large framework that'll be used for different problems.
seshagiric 18y ago
Try to go through the articles at: http://www.objectmentor.com/resources/publishedArticles.html http://www.objectmentor.com/resources/publishedArticles.html Most articles carry some example to go with the concept being explained.
- jonny_noog 18y ago
  Thanks for this and the other above replies. Regarding inheritance, I once had a conversation with a "application architect" who advised staying away from inheritance until you fully grok it, because it's easy to paint yourself into a corner with it (he then disappeared before I could question him further). The only issues I could think of at the time was stuff like say you have a bird class which contains a "fly" method, with duck and emu child classes (now I'm using the dodgy animal examples :P), the duck and most other birds should be able to fly, but the emu and some others should not. What is the better practice way of dealing with this issue? And what other adverse issues can arise when using inheritance? It has been recommended to me in the past that when it comes to systems that require more abstract objects, this is where researching design patterns would assist. However, pretty much all the design pattern literature I can find is not directly related to my current language of choice, Ruby. I can find lots of stuff talking about design patterns in Java and whatever else, which still provides some utility, but is there any books/articles that anyone can recommend on design patterns etc. using Ruby?
Spyckie 18y ago
Think about it from OO's creator's perspective. For instance, this is what the creator of inheritance probably thought: "All of these objects do very similar things. I don't want to have to write these functions over an over again if they're so similar..." and inheritance was born. Most OO concepts are about writing and seeing less code. I think the best way to grasp OO is to ban ctrl+c for anything longer than 2 lines. It really forces you to think about structure and code reusability, which is what OO is all about.

yters 18y ago

I mainly use it b/c it helps to easily swap out different implementations of a generic object. Useful if I'm coding a large framework that'll be used for different problems.

seshagiric 18y ago

Try to go through the articles at: http://www.objectmentor.com/resources/publishedArticles.html http://www.objectmentor.com/resources/publishedArticles.html Most articles carry some example to go with the concept being explained.

jonny_noog 18y ago
Thanks for this and the other above replies. Regarding inheritance, I once had a conversation with a "application architect" who advised staying away from inheritance until you fully grok it, because it's easy to paint yourself into a corner with it (he then disappeared before I could question him further). The only issues I could think of at the time was stuff like say you have a bird class which contains a "fly" method, with duck and emu child classes (now I'm using the dodgy animal examples :P), the duck and most other birds should be able to fly, but the emu and some others should not. What is the better practice way of dealing with this issue? And what other adverse issues can arise when using inheritance? It has been recommended to me in the past that when it comes to systems that require more abstract objects, this is where researching design patterns would assist. However, pretty much all the design pattern literature I can find is not directly related to my current language of choice, Ruby. I can find lots of stuff talking about design patterns in Java and whatever else, which still provides some utility, but is there any books/articles that anyone can recommend on design patterns etc. using Ruby?

Spyckie 18y ago

Think about it from OO's creator's perspective. For instance, this is what the creator of inheritance probably thought: "All of these objects do very similar things. I don't want to have to write these functions over an over again if they're so similar..." and inheritance was born. Most OO concepts are about writing and seeing less code. I think the best way to grasp OO is to ban ctrl+c for anything longer than 2 lines. It really forces you to think about structure and code reusability, which is what OO is all about.