• Post Reply Bookmark Topic Watch Topic
  • New Topic

Objects explanation  RSS feed

 
Donna Fuga
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In head first java objects are explained as having things the object "knows" and things the object "does". The examples given really confuse me! For example, Button object is given label and color as things the object knows, WHAT? How does a button know this? Then the button object has listed setColor, setLabel as things it does. I am now more confused, I thought I understood objects but this has really thrown me off! Can anyone clearly explain objects?
 
Dor Burd
Greenhorn
Posts: 19
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Objects have states or attributes (what they know) and they have methods (what they do).

The attributes are the characteristics of an object eg colour. Every time you create, say, a shirt object, that object will have a colour. If you have a bank account object, it will have a sort code, and a balance etc. These attributes are represented by instance variables and each object instance you create will have its own value of those variables.

So, you can create two shirts. Shirt1 will be red, but Shirt2 could be blue. Or it could be red too. Remember, a class is like a template, it's a definition of what this particular type of object has and does. Each Shirt object is an individual object so it doesn't matter if you've got two objects which are both red, they're separate objects, they're just identical.

In your example, a button has a label and it has a colour. The programmer is defining a button as something which has a label and a colour.

Methods are what the program does. For instance, a bank account would have a withdrawMoney() method. Some methods return the state of the object: a getBalance() method would display the balance (an attribute of the bank account object which is held in an instance variable) on the screen. Some change the state of the object. The button methods setColor() and setLabel() will both allow you to change the values held in the variables color and label.

Objects are about defining things. You're basically looking at the world and thinking about how you define something, how do you explain what it has to do. It's like giving somebody directions and beginning with explaining what a door is and how you get your body onto the other side of one.

 
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
Donna Fuga wrote:Button object is given label and color as things the object knows, WHAT? How does a button know this? Then the button object has listed setColor, setLabel as things it does.

  • Here in the following example an object of Button will have String lable and Color(enum) color as attributes ( Things the object of Button knows ) and setLabel, setColor, getLabel, getColor and toString as method Or behaviour ( Things It does ).
  • Here we have created two object of Button having different values of It's attributes.
  • Output:
    Properties of Submit Button: Label: Submit Color: GREEN
    Properties of Clear Button: Label: Clear Color: RED
     
    Julian West
    Ranch Hand
    Posts: 91
    3
    Chrome Java Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Donna Fuga wrote:Button object is given label and color as things the object knows, WHAT? How does a button know this?

    You tell it.

    Donna Fuga wrote:Then the button object has listed setColor, setLabel as things it does.

    You tell it these things also.


    The point is that this "knowledge" (fields) and "things that it does" (methods) are part of the object itself (members) rather than separate, independent code.
     
    Junilu Lacar
    Sheriff
    Posts: 11485
    180
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It helps to put objects and object-orientation into context by understanding the history behind object-oriented programming.

    Think of a program as a way of organizing data (things you know) and actions (things that can be done) on that data. Logic determines the sequence and timing of actions that are performed on the data and represents "knowledge" or "rules" of when and how to do things.

    Before object-oriented programming became widely adopted, the prevalent paradigm was procedural programming. Programming languages that preceded Java such as C, BASIC, Fortran, COBOL, and Pascal are all procedural programming languages. They are called "procedural" because programs written in these languages revolve mainly around organizing related logic and actions into subroutines/procedures. Data, however, is managed separately, often global accessible, and often shared by multiple programs/subroutines/procedures. Shared data/variables present numerous challenges related to complexity, maintainability, scalability, reliability, extensibility and many other quality attributes. Most of these issues can be addressed by increasing modularity, parameterization, and abstraction (i.e. hiding of implementation details). As systems get larger and more complex, however, managing the relationships between data and multiple actions becomes more difficult and complicated.

    Object-orientation emerged as a different way of organizing programs and managing the relationship between data and actions/logic. You can read up on the history of OOP here: https://en.wikipedia.org/wiki/Object-oriented_programming#History

    Just because Java supports object-orientation, that doesn't mean that all programs written in Java are object-oriented. I find it quite ironic that beginners are often taught how to program in Java in a very procedural way. There's practically nothing object-oriented in the way a typical Hello World Java program is written. Take the following example:

    The above is a procedural program written in Java. With programs this small, it doesn't really matter. Trying to make this more object-oriented will actually make it more verbose and complicated. However, as a program gets larger and more complicated, you'll eventually reach a tipping point where the problems and inadequacies of procedural programming in managing complexity and abstractions will become very apparent. It's difficult to demonstrate where this tipping point occurs with a small program example but we can go through a progression so you can start to see how object-orientation differs from procedural programming.

    (continued)
     
    Junilu Lacar
    Sheriff
    Posts: 11485
    180
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    (continued)

    Say you now want to extend the program to be able to greet in different languages. To do that, you might try this:

    This is still a procedural program because it's organized as a single procedure, main(), and static data (all those GREET_xxx constants). Still not a big deal.

    Now, let's put this into the context of a bigger program where you have people logging in as users, each user having their own preferred language. You want the program to display a greeting based on the user's preferred language. What kind of changes would you need to make to be able to do that?

    The way you organize the solution in procedural programming will be very different from the way you'd organize it in an object-oriented way. A more object-oriented solution might look something like this:
    Object-orientation is mainly about assigning specific responsibilities to program entities (objects/classes). Data or "knowledge" about how those responsibilities are carried out is kept close to those responsibilities (encapsulated) and access to that knowledge is kept strictly on a need to know / need to use basis.

    Note how things are organized in the above program outline. Each class does specific things (has specific responsibilities). The LoginHandler class acts as kind of a coordinator. When a user logs in, the LoginHandler.onLogin() method presumably would get called. The method will ask the user object that was passed for their preferred greeting (by calling the user.getPreferredGreeting() method) and then passes that information on to a Context object. The Context object in turn takes the information and uses it to display a message that will be seen by the user. A LoginHandler doesn't care how a user object keeps track of his/her preferred greeting. That logic or "knowledge" is encapsulated in the user object, the actual details of which are further abstracted away through the Preferences, Messages, and ResourceBundle classes. The LoginHandler doesn't need to know all that detailed stuff though. All it "knows" is that a user can tell it what greeting it prefers and that a Context object can display that greeting if you tell it to by calling setAttribute() with parameters of "greeting" and the actual string. How that actually happens is the sole concern of the Context object.

    Going back to your original example, it's unfortunate that setColor() and setLabel() were the examples given for things that the Button object does in contrast to its label and color fields as things that it knows. I can see how that is confusing to you.

    It might make more sense if the example were like this:

    Here, the button "knows" its color, its label, and how to draw itself (an action it can perform).  The color and label data is kept private within a button and logic about how to draw a button on a Display object is encapsulated in the draw() method. In higher level code, you'd just see something like:

    Note again how specific actions each object can perform and the information that is needed to perform those actions are organized in a way that keeps them together. More importantly, details (both data and logic) are mostly hidden and/or abstracted away from other things that don't need to be concerned about them.
     
    Don't get me started about those stupid light bulbs.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!