The Student Room Group

Object Oriented Programming and where to start with Java?

I'm currently 16 year old, and I'm hoping to grasp a general idea of how object oriented programming works and what it is, and I want to be able to apply that knowledge to any programming language so that I can learn it easier.

My main goal at the moment is to learn Java, I know the basics of Python from my Computing GCSE. Can anyone give me a starting point from which I can learn about object-oriented programming and learn the basics of Java and its syntax? Thanks.
Original post by faizanistall
snip


There are plenty of Java tutorials online to help you grasp the basics of the language. To learn OOP principles I would consider buying Design Patterns: Elements of Reusable Object-Oriented Software; it is a great book, but can be quite difficult to read/reason about if you don't know how to program. If you want a slightly more advanced book that will give you an aggressive introduction to Java, consider Effective Java by Joshua Bloch. Otherwise, Java Precisely is pretty good.
(edited 8 years ago)
Reply 2
Try to learn object orientation separately, then apply it to Java.
I'd recommend to have a good solid foundation in the basics of programming before moving onto object orientation.

Here's a decent YouTube tutorial.
https://www.youtube.com/watch?v=jwLv1Aq_HnQ

The main principals involved in object orientation programming( OOP) is, Polymorphism, Inheritance, Instansiation and Encapsulation.
Object orientation is pretty much coding that represents real life objects. For example let's say we can to create a Dog. We can create a Dog object like this.




In our main we can use it as such.




See! So in OOP, an object is just a blueprint to model anything. Offcourse OOP is way more complex than this but this is just a basic. I would recommend just to practise the examine I just written, play around with it. Make your own object and move on from there. Look up on the NET for more examples. Good luck
(edited 8 years ago)
Original post by Async
snip


Four main pillars: Inheritance, polymorphism, encapsulation, abstraction.

Object orientation is pretty much coding that represents real life objects.


This is called abstraction.

Class attributes should not be public; use getters/setters. *encapsulation*

For class members you should use lowerCamelCase, not Upper.

Why are there no constructor methods?

I think you meant a class is a 'blueprint', not an object.
Reply 4
Original post by Jooooshy
X



Four main pillars: Inheritance, polymorphism, encapsulation, abstraction.


I wasn't taught abstraction in college. We were taught "OO PIIE". Object Oritentation Poly Inheritance, Instanciation and Encapsu

I'm more than aware of the points you have made. I understand the coding convections for Java is camel casing. But for the purpose of the specific post. I understand encapsulation very well, I chose to have those attributes as public for simplicity sake.
Why should I made a getName() or setName(), that would be confusing in a way.

Object oritentation looks simpler without the verbose getters and setters Java have, that's why I prefer C# when it comes to those type of things because they handle it much better. With C# you do it all with properties which are a nicer version of getters and setters. Getters and setters are probably one of the things I hate about Java and is why java is so verbose. In C# class attributes can be public :smile:

There were no constructors because that might be confusing for OP to wrap his head around. I mean, for someone who is new to OOP, constructors should be taught later on after main concepts are down. Also, why stop at Constructors? Why not destructors?

Having constructors is not relevant right now in this object. Imagine,
Dog dog = new Dog("Jim");
It's not all that relevant. If we were creating a Human object then maybe yes.
Human josh = new Human("Joshy");
Plus this is a simple introductions, with my style of teaching, I like to teach from bottom up, if I had more time to construct a proper answer I'd probably teach how to do this without a class. SoString dogName = "Bruce";
String dogOwner = "Async";
String dogBreed = "Pb";


String dogName2 = "James";
String dogOwner2 = "Josh";
String dogBreed2 = "Pb";
Then from there introduce the concept of classes and why it's better to use in this situation. There's method to my madness :wink:
(edited 8 years ago)
Reply 5
Original post by Jooooshy
X .


Apologies for the somewhat defensive reply, I get a bit defensive when I get picked out on something I know. Maybe I should of made it clear in my post that I this was just a simple watered down example.
Original post by Async
I understand the coding convections for Java is camel casing. But for the purpose of the specific post.


You should make a conceited effort to follow them, especially when giving an example from which you expect people to learn!

Object oritentation looks simpler without the verbose getters and setters Java have, that's why I prefer C# when it comes to those type of things because they handle it much better.


That may be, but giving an example of OOP and violating encapsulation is not a cool thing to do!

There were no constructors because that might be confusing for OP to wrap his head around. I mean, for someone who is new to OOP, constructors should be taught later on after main concepts are down. Also, why stop at Constructors? Why not destructors?


Java doesn't have a destructor: it's GC. I only mentioned constructor methods because I think it's slightly intuitive to pass the dog's breed as a parameter. Setting a dog's breed is a little silly. (Hence why I think a constructor is relevant).

Apologies for the somewhat defensive reply, I get a bit defensive when I get picked out on something I know. Maybe I should of made it clear in my post that I this was just a simple watered down example.


It's absolutely fine! :smile:
Reply 7
Original post by Jooooshy
You should make a conceited effort to follow them, especially when giving an example from which you expect people to learn!

That may be, but giving an example of OOP and violating encapsulation is not a cool thing to do!

Java doesn't have a destructor: it's GC. I only mentioned constructor methods because I think it's slightly intuitive to pass the dog's breed as a parameter. Setting a dog's breed is a little silly. (Hence why I think a constructor is relevant).

It's absolutely fine! :smile:


Well, there's not much I can say here. You're pretty much correct on every point. Thanks for the heads up though!
If you already know Python and want to understand object orientated programming I would recommend you look at it in the context of Python programming - that way you just have to focus on learning OOP rather than OOP + another language.

I've had a glance at this tutorial and it seems decent.
Reply 9
Original post by Jooooshy
Four main pillars: Inheritance, polymorphism, encapsulation, abstraction.



This is called abstraction.

Class attributes should not be public; use getters/setters. *encapsulation*

For class members you should use lowerCamelCase, not Upper.

Why are there no constructor methods?

I think you meant a class is a 'blueprint', not an object.


Encapsulation is abstraction.
Not using camel case is really not post worthy.
Everything within the class is encapsulated, any client that uses the services offered by the class does not need to know how it works.
Not every class requires a constructor method.

You seem to have just chimed in for no reason or benefit to the op.

Op, get any book on oop, it's really not complicated at all, start thinking about a personal project you can do to help you learn
Original post by tim_123
Encapsulation is abstraction.


No it is not.


Not using camel case is really not post worthy.


I didn't write the post solely to point it out.

Everything within the class is encapsulated, any client that uses the services offered by the class does not need to know how it works.


Oh dear, no it isn't..

Dog1.Breed = ...

Not every class requires a constructor method.


That's not what I said, although I do think that this class requires one.
(edited 8 years ago)
Original post by Jooooshy
There are plenty of Java tutorials online to help you grasp the basics of the language. To learn OOP principles I would consider buying Design Patterns: Elements of Reusable Object-Oriented Software; it is a great book, but can be quite difficult to read/reason about if you don't know how to program. If you want a slightly more advanced book that will give you an aggressive introduction to Java, consider Effective Java by Joshua Bloch. Otherwise, Java Precisely is pretty good.


Effective Java hurt my brain :tongue:.
Original post by keromedic
Effective Java hurt my brain :tongue:.


I'm pretty sure that books hurts everyone's brain!
Original post by Jooooshy
No it is not.



I didn't write the post solely to point it out.



Oh dear, no it isn't..

Dog1.Breed = ...



That's not what I said, although I do think that this class requires one.


Abstraction as encapsulation.... Hiding the inner workings of the model behind some interface. The model being the class, the interface being the way some client code interacts with that class. Ie, dog1.getBreed(). The client is not concerned with how the getBreed() method works, just that it returns the breed of the dog.
Original post by tim_123
Abstraction as encapsulation.... Hiding the inner workings of the model behind some interface. The model being the class, the interface being the way some client code interacts with that class. Ie, dog1.getBreed(). The client is not concerned with how the getBreed() method works, just that it returns the breed of the dog.


What are you talking about? There is no getBreed() method. The inner workings of this class are completely exposed.
Original post by Jooooshy
What are you talking about? There is no getBreed() method. The inner workings of this class are completely exposed.

I was using an example.

If the class has a public method geBreed(), then the inner workings of this method is encapsulated behind the getBreed() interface to any code that uses this interface outside of the class. That's abstraxtion as encapsulation
(edited 8 years ago)
Original post by tim_123
I was using an example.

If the class has a private method geBreed(), then the inner workings of this method is encapsulated behind the getBreed() interface to any code that uses this interface outside of the class. That's abstraxtion as encapsulation


What point are you trying to make?
You stated that the class does not represent abstraction. I'm pointing out that it does.
Original post by tim_123
You stated that the class does not represent abstraction. I'm pointing out that it does.


I didn't state that anywhere..

Quick Reply

Latest

Trending

Trending