• Post Reply Bookmark Topic Watch Topic
  • New Topic

reading some stuff about OO in head first java  RSS feed

 
jon ninpoja
Ranch Hand
Posts: 291
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
was re-reading a section on classes and objects in head first:

"A class is a blue print for an object...it tells the virtual machine how to make an object of that particular type.
Each object made from that class can have its own values for the instance variables of that class.
eg:you might use the Button class to make dozens of different buttons,and each button might have its own
color,size,shape,label etc.

so if i have a class



i know i can make or instantiate a button from the class by
Button fireButton = new Button ();

how would i manipulate the instance variables or create a new object that is slight different from the previously created button,or one i create after.
is it just done through parameters?





 
fred rosenberger
lowercase baba
Bartender
Posts: 12563
49
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As written, there's not a lot you can do. Your member variables are all private (which is the right way to do it).  You would need to either

a) write some setter methods that let you update the value once the object is created
- or -
b) write a constructor that would let you set the variables when you create each instance.
 
Paul Clements
Ranch Hand
Posts: 99
1
Chrome Eclipse IDE MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
jon ninpoja wrote:how would i manipulate the instance variables or create a new object that is slight different from the previously created button,or one i create after. is it just done through parameters?

As the post above says, you either need a multi-argument constructor (the default method which runs when you create an instance of a class)
Therefore to create a Button object you would do something like
OR a setter to allow instantiation of values via method AFTER the object has been created.

You would then do something like:
 
Ganesh Patekar
Bartender
Posts: 726
23
Eclipse IDE Hibernate jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clements wrote:You would then do something like:
setColour, setSize  etc are methods so It suppose to be


 
Paul Clements
Ranch Hand
Posts: 99
1
Chrome Eclipse IDE MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ganesh Patekar wrote:
setColour, setSize  etc are methods so It suppose to be

Of course, my mistake. That's what happens when you post in a rush at 11:30pm i.e. embarrassment:-)
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
jon ninpoja wrote:how would i manipulate the instance variables or create a new object that is slight different from the previously created button,or one i create after.
is it just done through parameters?

As you can see, there are several ways to do it, but one perfectly valid option which has not really been covered is not to allow internal fields to be changed AT ALL.

Classes like this are called "immutable", and they have many advantages - not the least being that they are naturally Thread-safe. And just because a class is immutable doesn't mean that you can't do some very useful things with it. java.lang.String is just one example of an immutable class that you can do all sorts of things with, but almost all its "manipulation" methods return a new String object, rather than changing the one you run the method on.

Obviously, it isn't appropriate for every kind of class - for example, if you have a Person class, you'll probably want a changeName() method - but you'll be surprised how many classes can be made immutable. And even for classes that you can change (these are called "mutable"), you'll probably want to keep the number of things you can change to a minimum.

So the general rule is: write as many "getter" methods as you like; but think three times before you write a public "setter" method - and in particular, think ten times before you write the first setter method for a class.

HIH

Winston
 
Campbell Ritchie
Marshal
Posts: 56541
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is more about immutability in the Java™ Tutorials. It is possible to write programs comprising only immutable objects, but you need a slightly different style. You will find this:-
Only one field refers to an object, and that object is itself immutable. Therefore, no safeguards against changing the state of "contained" mutable objects are necessary.
...in that link. If you ever find yourself with a mutable reference type as a field (that includes arrays which are always mutable if they have > 0 elements), find Joshua Bloch's book Effective Java and read the section about defensive copies.
 
jon ninpoja
Ranch Hand
Posts: 291
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks for all your feed back ...great help!!!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!