macOS Understanding Object Orientated Programming

[Izzywizz]

This sounds like a contradictory statement but I know how to use OOP design with my programs but I don't understand the theory as well as I wish.

Does anyone know a really good book or website that really drives it home, with topics such as Abstraction, Encapsulation and Inheritance, explained in detail for a beginner basically.
It doesn't have to be language specific but real world examples alway help. The book/ website doesn't have to be high brow or anything like that just something that lets me grasp the principles more soundly.

 

[chown33]

I think an answer is going to depend on exactly what you mean by "a beginner".

You say you know how to use OOP in design, which doesn't seem like "a beginner" to me. Are you saying that you employ OOP in some kind of rote fashion, or is there some specific thing you consider yourself a beginner at?

One principle in all problem-solving, hence all programming, is Break Things Down. Exactly what problem are you trying to solve (self education), and exactly what basis are you trying to solve it from (unstated)? Given this breakdown of your post into two parts, the problem domain of self education can be broken down more specifically, and the basis for a solution needs to first be stated and then broken down.

You've given no realy concrete information about what your knowledge level actually is, and that makes your description vague. Vague questions are hard to answer with any degree of specificity.


What Have You Tried?

In other words, explain what you tried (searching, books, tutorials), what you found, and why those didn't meet your goals.

Be specific. If you've tried books, list their titles & authors. If you tried searching, list the search terms. If what you found didn't meet your goals, be specific about why. That is, if a book assumed that the reader was already familiar with the principles of inheritance and encapsulation, so it didn't explain their purpose, then say that.

Being specific also gives us more information on the basis you're solving the problem from, i.e. your base of knowledge.


That said, have you tried browsing articles on Wikipedia? Example:
http://en.wikipedia.org/wiki/Object-oriented_programming

Wikipedia articles aren't valuable just for what they say, but for what else they link to. For example, one important part of OOP is encapsulation. It's not unique to OOP, but it is a fundamental thing. So in the OOP article, don't just read it's discussion of encapsulation, read the linked article on encapsulation, too.

Also look at the citations listed in each article's See Also and References sections. More than once I've started with a Wikipedia article, combed through its References and See Also's, and found much more details and better in-depth explanations of the material.

I also find the Criticisms heading (if there is one) useful, because sometimes the best way to really understand what something is (or proposes to be) is to understand what it isn't.


Finally, one of the principles of OOP is Liskov substitution:
http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

It's one of 5 principles with the mnemonic SOLID espoused in a popular book. The SOLID article's link is in the See also section of the first OOP article linked to above.

My point here is that the path from search terms to core principles is pretty short:
1. Search on Wikipedia for object oriented.
2. Visit article on OOP.
3. Visit article on SOLID listed in See also.
4. See 5 principles of SOLID.
5. Visit article on Liskov substitution.

Some of the SOLID principles also apply in procedural programming, so don't take those principles as unique characteristics of OOP.

 

[larswik]

Your not alone Izzywizz. I have been coding on and off for years now and some simple things still allude me.

But, Abstraction hit me last year and I had my ah-ha moment, I get it. I will try and explain it simply, as I know it.

I was working on an app a while back and was setting the screen size for graphics like X=320 and y=480. When different screen sizes came in with iPhone 5 I had different sizes to work with and had a bunch of IF statements defining different screen sizes.

It was recommended to me to ask the hardware what the screen size was instead of telling it 320 x 480. So now it is something like x = screenSize.x and y = screenSize.y. That made the code more ABSTRACT and made that code future proof for screen sizes. In other words it made the code less specific, I wasn't giving it numbers to define it's dimension, it was getting them by asking the hardware now.

So that is just an example that made me finally understand Abstraction. Now I approach writing methods this way. Instead of having 3 different methods that return a red,green or blue circle. I have 1 method that I pass in the color information that creates what ever color circle I need from 1 method. It became more abstract. The method had less specific code in it defining the return object. Instead I pass in the information size, color and the method returns it. That method is now more abstract.

 

[subsonix]

There are books on object oriented design principles available, but I never understood how it was warranted to fill an entire book with that. That is to say, if you already use it, you probably understand it. Abstraction and encapsulation comes into play in other languages as well, just writing a typedef or function is an example of abstraction, and in case of the function, also encapsulation since variables and the implementation are local to the function. If you for example create a clock class, then that enables you to talk about and handle a clock object on "clock" terms without regards to implementation details. You've risen to a higher level of abstraction, getting rid of irrelevant details (as far as a clock is concerned) out of the way.

Inheritance isn't necessarily part of OOP, depending on who you ask, but it's just a means to extending existing classes with new functionality, making use of code someone else already wrote. A similar concept is composition, where you wrap an existing class inside yours, it's more flexible and more modular since you can wrap several classes and also make changes easier later on without regards to dependencies.

 

[olup]

I learned about abstraction, encapsulation in this book called Objects First with Java, which helped me to understand those concepts a bit better.

 

[Izzywizz]

I should of elaborated more, I have been reading Programming Principles and Practices using C++ and Java How to program.
The books are ok but I feel like it hasn't just clicked in my brain of the reasons behind why and how of OOP design.

While I understand how to use classes and methods and that encapsulation is about securing your fields using a private class and accessing them with public methods, I feel like my knowledge is not 100% or just used in sort of round a bout way.
A friend asked to explained abstraction (thank you for the example larswik that was exactly what I was after, some real world context) and I explained it badly and I was left more confused then he was haha.
I will read into on wiki and scour the web for a few more examples, cheers Olup I will check out that book.

I guess I wanted some direction and bedtime reading, to understand the four important areas of OOP design; encapsulation, inheritance, polymorphism, and abstraction with some easier to understand examples without cluttering it with nonsense code.

 

[ArtOfWarfare]

I should of elaborated more, I have been reading Programming Principles and Practices using C++ and Java How to program.
The books are ok but I feel like it hasn't just clicked in my brain of the reasons behind why and how of OOP design.

While I understand how to use classes and methods and that encapsulation is about securing your fields using a private class and accessing them with public methods, I feel like my knowledge is not 100% or just used in sort of round a bout way.
A friend asked to explained abstraction (thank you for the example larswik that was exactly what I was after, some real world context) and I explained it badly and I was left more confused then he was haha.
I will read into on wiki and scour the web for a few more examples, cheers Olup I will check out that book.

I guess I wanted some direction and bedtime reading, to understand the four important areas of OOP design; encapsulation, inheritance, polymorphism, and abstraction with some easier to understand examples without cluttering it with nonsense code.

It sounds to me like part of your problem is you haven't written enough code yourself. Things generally click for me when I struggle with writing my own code for long enough without using that things that I wasn't able to grasp previously, and I just keep thinking "there must be a better way to do this" when all of a sudden I get it and I realize "holy crap, this is what everyone was talking about all along, this is where I need to use it". Happened for me with OOP, MVC, source control, recursion, pointers, lambdas, properties... I'm sure there are other things...

Heck, I remember how variables and functions made no sense to me when they were taught to me in Algebra I, but overnight they made sense to me when I started learning C. That was when I first started learning to code... about 10 years ago now?

So my point is... don't worry about these concepts. Instead, dive into coding. And when you feel yourself getting frustrated and like there has to be a better way, ask about it and that'll serve as the perfect moment to introduce the right concept to you. You'll be especially motivated by your frustration from trying to code without it.

 

[larswik]

It sounds to me like part of your problem is you haven't written enough code yourself.

Some times that is also a problem. When you learn from a book and just write code you, or I should say I, developed bad syntax styles. After learning C, I took a Pascal class at a city collage. I found it was so important to talk to other programmers and ask questions in class that I understood more and my writing got better. The more you learn the better your writing gets and can see more tools to use in your projects.

But like you, when you stair at code long enough you say "There has to be a better way". I don't know if my apps are written well but they work. Sometimes when I spend months writing a program I find better ways of doing it and end up rewriting it.

But one thing is for sure, I am glad I spent the time to learn programming. I look forward to Friday nights, good music and programming! I wish I would have started young, like 13 back in the Zork days!

 

[firewood]

This sounds like a contradictory statement but I know how to use OOP design with my programs but I don't understand the theory as well as I wish.

Your not alone Izzywizz. I have been coding on and off for years now and some simple things still allude me.

You say you know how to use OOP in design, which doesn't seem like "a beginner" to me.

This is the classic difference between a scientist and a mechanic. A mechanic might know how to make some widget, but have little idea how they work. Or in some cases even the wrong idea, but still ended up with a working widget. And then there are the scientists, who might perfect the theory on paper or the blackboard, but have no idea where to start in an actual machine shop (without cutting/burning themselves) to get build anything that functions according to that theory.

The theory of OOP is a subject of computer science (formal verification,etc.). Writing OOP programs is software engineering (code formatting,debugging,etc.). Hopefully, one learns some overlap so that they have some idea of why what they are making works.

 

[subsonix]

The theory of OOP is a subject of computer science (formal verification,etc.). Writing OOP programs is software engineering (code formatting,debugging,etc.). Hopefully, one learns some overlap so that they have some idea of why what they are making works.

Yes, but a class on OOP concepts is usually a prerequisite to a Java 101 class. Formal verification belongs more in math, proofs and logic, (not to say that it's not therefor a part of computer science) but a lot of books on OOP seems like an excuse to sell large books with big sounding words. I do agree that it's important to understand what it is and how it works though, and if a book helps with that, by all means read such a book.

 

[larswik]

The theory of OOP is a subject of computer science (formal verification,etc.). Writing OOP programs is software engineering (code formatting,debugging,etc.). Hopefully, one learns some overlap so that they have some idea of why what they are making works.

That's a great way of putting it. I have been saying learning the code is like adding tools in your machine shop. You may have the tools but you still don't know how to rebuild an engine. Programming is a 2 part process.

 

[Izzywizz]

Right, well its clear ive let myself get rusty, I'm going to dust off my old uni notes, I used to record lectures as well hahaha, my memory being terrible and dive in deep with some even more coding, as ArtOfWarfare suggested, more than likely Java as im comfortable with the syntax.

Unfortunately I don't get a chance to ask developer questions but I will probably bug you guys or scour the internet, my biggest problem is I hate someone showing me the answer, I love to figure it out myself plus there is always dozens of a different solutions to a problem, which is what I love, anyhows im waffling.

Thank you for all of your responses, if anyone has a good book on theory/programming they would recommend or even a iTunes U lecture/podcast or something then please do.

 

[chown33]

Thank you for all of your responses, if anyone has a good book on theory/programming they would recommend or even a iTunes U lecture/podcast or something then please do.

Visit your local public library. Look for a "for Dummies" book on OOP or Java. Also look for programming books intended for teens or kids. The latter are often simplified yet well-written.

You're the one person best qualified to determine if a book matches your current skill level and your intended goal.