Author Topic: Am I getting the concept down?  (Read 2280 times)

0 Members and 1 Guest are viewing this topic.

Offline Machinegun Kelly

  • NULL
  • Posts: 3
  • Cookies: -1
  • Dedication and Perseverance.
    • View Profile
Am I getting the concept down?
« on: December 05, 2013, 10:30:47 pm »
I am studying a Java programming book. There is a question in the book, and I wrote my answer down.


I ask, here on this board, what do y'all think of my answer?


What are the fundamental things you need to think about when you design a Java class?
 
When designing a Java class, it is important to prepare for possible spec changes (Plan for future problems, or possible occurrences).  Such as, if you have several objects w/ specific functions you should make a superclass if they all have the same method.
Your objects (the other classes) are the sub classes in your design that inherit their method from the superclass. Of course, there is the option of overriding the superclass from your sub class.
Using objective oriented programming when you have several classes is very nice, for when you have to edit code. All you have to do is add another object for example, rather than having to go through code and basically re-write it.

Offline Kulverstukas

  • Administrator
  • Zeus
  • *
  • Posts: 6627
  • Cookies: 542
  • Fascist dictator
    • View Profile
    • My blog
Re: Am I getting the concept down?
« Reply #1 on: December 06, 2013, 07:38:24 am »
Your answer is all correct, however I'd like to add to that.
When you are trying to prevent repetitive code, you don't have to make sub-classes or different classes at all if you will only have 1 or two methods in there, but some might disagree with that. Defining constants is a must for everything!
Also when coding classes, you have to keep the main class neat and  tidy (as the whole code :)), move functions, that doesn't directly use the main class, somewhere else, you can return whole objects, not just values.

Yes, this is the beauty with OOP, everything is an object.

BTW it's Objective Oriented Programming

Offline vezzy

  • Royal Highness
  • ****
  • Posts: 771
  • Cookies: 172
    • View Profile
Re: Am I getting the concept down?
« Reply #2 on: December 06, 2013, 03:01:36 pm »
Yes, this is the beauty with OOP, everything is an object.

Only in Smalltalk.

In Nygaard-model OOP languages like Java and C#, which make use of a quasi-procedural syntax, primitive data types are not objects, thus the languages are not purely OO.
Quote from: Dippy hippy
Just brushing though. I will be semi active mainly came to find a HQ botnet, like THOR or just any p2p botnet

Offline MadHippie

  • NULL
  • Posts: 2
  • Cookies: 0
    • View Profile
Re: Am I getting the concept down?
« Reply #3 on: January 12, 2014, 10:26:10 am »
Only in Smalltalk.

In Nygaard-model OOP languages like Java and C#, which make use of a quasi-procedural syntax, primitive data types are not objects, thus the languages are not purely OO.

This is interesting. I had heard in passing that Java "was not purely OO". Is what you're mentioning called autoboxing? For example, int char byte are not objects. Is this the right concept?

I'm Week 1 into a Java programming class (but I have been reading a head way before class), so I am trying to nail this down.
« Last Edit: January 12, 2014, 10:27:37 am by MadHippie »

Offline Teddy

  • /dev/null
  • *
  • Posts: 12
  • Cookies: 8
    • View Profile
Re: Am I getting the concept down?
« Reply #4 on: January 12, 2014, 12:25:29 pm »

Quote
[size=78%]This is interesting. I had heard in passing that Java "was not purely OO". Is what you're mentioning called autoboxing? For example, int char byte are not objects. Is this the right concept?[/size][/color]

Boxing/Unboxing is the process of converting a primitive datatype like int, char, byte into an Object (or vice versa). In Java you have for every primitive datatype a class which basically represents it as a class e.g:
class Integer { private int value; //Methods}.


The process of extracting the value out of an object or storing such value inside a object is called unboxing/boxing.
Code: [Select]
Integer i = (Integer) 42;
int x = i.intValue();


You need this to pass a primitive datatye by reference instead of by value and to store it inside container class like ArrayList


Java also has static methods which aren't so OO.[size=78%]http://stackoverflow.com/questions/4002201/why-arent-static-methods-considered-good-oo-practice[/size]
« Last Edit: January 12, 2014, 12:26:41 pm by Teddy »

Offline Deque

  • P.I.N.N.
  • Global Moderator
  • Overlord
  • *
  • Posts: 1203
  • Cookies: 518
  • Programmer, Malware Analyst
    • View Profile
Re: Am I getting the concept down?
« Reply #5 on: January 12, 2014, 01:03:13 pm »
Boxing/Unboxing is the process of converting a primitive datatype like int, char, byte into an Object (or vice versa). In Java you have for every primitive datatype a class which basically represents it as a class e.g:
class Integer { private int value; //Methods}.


The process of extracting the value out of an object or storing such value inside a object is called unboxing/boxing.
Code: [Select]
Integer i = (Integer) 42;
int x = i.intValue();


You need this to pass a primitive datatye by reference instead of by value and to store it inside container class like ArrayList


Java also has static methods which aren't so OO.[size=78%]http://stackoverflow.com/questions/4002201/why-arent-static-methods-considered-good-oo-practice[/size]

Although you probably meant the right thing, your explanation is not exactly right.
Autoboxing and unboxing is done by the compiler and it is only done between the primitve types and their corresponding wrapper classes (int <-> Integer, double <->Double, but NOT int <->Double and NOT int <->SomeObject). It is NOT a conversion from a primitive to an object.

There are only two ways, when autoboxing or unboxing is applied by the compiler. You either assign a primitive value to the corresponding wrapper class (or vice versa for unboxing) or you pass a primitive value as parameter to a method that expects the corresponding wrapper class (or vice versa for unboxing)

Your first example is an unneccessary cast (casting != autoboxing):

Code: [Select]
Integer i = (Integer) 42;
What happens here is that the compiler does the autoboxing by applying this instead:

Code: [Select]
Integer i = (Integer) Integer.valueOf(42);
Now you see why the cast is superfluous.

Your second example is what the compiler would do from

Code: [Select]
int x = i;
Also: You can not pass by reference in Java, but you can pass references  (by value)
However that's not why you need the wrapper classes.
I would like you to try the following code:

Code: [Select]
public static void main(String[] args) {
   Integer val = 2;
    increment(val);
    System.out.println(val);
}
   
public static void increment(Integer i) {
   i++;
}

Although a reference type is used, you can not change the value of val this way.
The reason is that an Integer is immutable (as well as the other wrapper classes).
So passing the reference is not of any use.

The only reason for wrapper classes is that you can use primitive values with generic classes and interfaces and so you can call methods on them every object has, like equals. Collections are one example you already mentioned.

This is interesting. I had heard in passing that Java "was not purely OO". Is what you're mentioning called autoboxing? For example, int char byte are not objects. Is this the right concept?

What vezzy mentioned didn't include any autoboxing. He just said, Java has types that are no object, thus it is not a pure object oriented language.
Autoboxing is just there to have cleaner, better readable code. You can perfectly live without it, but you would have to do the wrapping of primitive values explicitly all the time. So it is just a matter of convenience to have autoboxing.
« Last Edit: January 12, 2014, 01:10:37 pm by Deque »