Thinking in terms of Objects.

JAVA

    Sponsored Links

    Next

  • 1. about certificate
    I was told by many people that a Java or C++ certificate does not prove anything. Perhaps it is true that experience is much more import than a piece of paper - certificate. If you don't have very much experience, how do you prove that you know them well. I often did a lousy interview, I could not answer the questions well. I know I can do the works C++ and Java. How are Java and C++ graded ? Are they graded by assor ail basis ? I would like to have your opinions and/or suggestions. Thanks in advance.
  • 2. Random Enum
    Hi there, To get a Random enum you need something along those lines. <code> public Days randomDay() { Days[] days = Days.values(); return days[(int) (Math.random() * days.length)]; } </code> But what if I want to generalize this code. Is it possible that my method accepts just any enum, gets it's .values, gets one Random value from it and returns it? Anybody care to share his ideas and maybe some code? Greetings, -- Daniel Berger Send files in free open formats.

Thinking in terms of Objects.

Postby naveen_reddy_2004 » Sun, 25 Jan 2004 14:12:58 GMT

Hello all,

I come from a background of Unix C-shell, WIN .bat programming and am
entirely new to the concepts of Object-Oriented programming.

I'm having a hard time geting the concept of 'objects', 'classes',
'why to use them', 'when to use them' etc. I have bought couple of
books on OOPS, but they dont tell me why I should use objects and not
the regular 'functions' or whats the diff. between the two.

I'm sure a lot of people out there would've had a similarly
frustrating experience when making the switch from Structural to
Object-oriented, like the switch from C to C++ or the first time OOPS
was introduced in Visual Basic or Perl. I'm interested to know about
your experiences during the transistion and what you had to do?

Also, for starters, I've made couple of home-grown definitions of what
I think are OOPS fundamentals. Could you please tell me if I'm on the
right track?

1.  Objects are glorified functions:
Ojects are just like functions, as in, you have a code-block you think
might have to be repeated over and over again in your program. Might
as well write it once and keeping using it. Objects are these
code-blocks.

2. Objects are user-defined data-types:
Objects are just like int, float, double etc., but you get to define
them!
User defines what sort of data and its attributes an object has holds.

I know they are defined in a gazillion different ways but, is this a
good way to start? Did I miss any other fundamental concepts of
Objects?

Another thumb-rule I'm thinking of implementing till I get a hang of
the Objects:  Always try to objectify every darn piece of executable
statement as a first resort.

Your comments, please.
Also, any books/URLs you'd recommend for the absolute beginner in
Objects( with reference to Java, especially).

Thanks for your time,
Reddy

Re: Thinking in terms of Objects.

Postby JavaJunkie » Sun, 25 Jan 2004 14:55:34 GMT

Check this free book out: Thinking in Java, 3rd ed. Revision 4.0 at
 http://www.**--****.com/ 

Section 1 (Introduction to Objects) is probably the best description of this
concept I have found.










Re: Thinking in terms of Objects.

Postby Linus Norton » Sun, 25 Jan 2004 16:08:05 GMT

although i have little 'real' experience with programming i did start out
doing functional stuff and move to OOP and i did also think that OOP didnt
really offer many differences but the more u use it the more useful it
becomes. For me id say that the main advantage is that it is much easier to
modularize the code and maintain it. Id say most of the benifits are in the
design stage.

Linus



Re: Thinking in terms of Objects.

Postby Patrick B. Haggood » Sun, 25 Jan 2004 18:58:22 GMT

Another good source would be the bluej ide (www.bluej.org).  Located there
are some tutorial links, the free IDE itself and some other resources. 
Also, a really good learning tool is {*filter*}objects @ www.nakeobjects.org;
there's some really nifty OO-based tools and other resources to be had
there, too.





Re: Thinking in terms of Objects.

Postby Jon A. Cruz » Sun, 25 Jan 2004 19:25:42 GMT



Mine's a bit different than that. I had been getting more and more 
"OO-ish" in my C programming when C++ became a more viable solution and 
I started to transition. Plus I had already learned OO with Lingo in 
Director, plus a little others.


Nope. Not really.

Objects are abstract concepts of things. They have data members for 
properties of their "thingness", and functions or methods for doing 
operations with them as "things".



No. Not really.



Yes. Stop thinking in terms of functions and data. Take a step higher up 
and see if you can represent your primitives and functions as dealing 
with concepts of 'things'.


Well... close. But rather, try saying "what 'thing' does this code 
belong to?" If it belongs to none of the 'things' you already have 
defined, then it could belong to a new 'thing' you have yet to define 
for your program.

For example, if you have a function to split a person's name into parts, 
don't.  :-)
Instead, think "gee, what 'thing' does this work with?" In this case it 
could be a class "ProperName", or perhaps as part of a "Person" class.

Then maybe you'd start to thing of what you'd have more than just a bare 
string for a name. Maybe have Person.getFirstName(), 
Person.getLastName(), Person.getFullName(), Person.compareName(String)...




'Thinking in Java' is probably a very good one for the sort of approach 
you seem to need.


Re: Thinking in terms of Objects.

Postby Oscar Kind » Sun, 25 Jan 2004 19:53:15 GMT

n comp.lang.java.help Naveen Reddy < XXXX@XXXXX.COM > wrote:
[A C coder learning OOP]

No. As long as you think this, you'll have difficulties. You are partially
correct about the code block though, but there is more to it (member
variables for instance).

Objects are an abstraction layer. They exist so each part of your program
has only a very limited set of data available. This makes each individual
part easier to understand and thus maintain.

Personally, I had difficulty understanding objects until I let go the
notion "a program consists of ocde". Instead, I see in now as:
- A program consists of interacting objects
- Each object has a state (member variables) and interaction possibilities
(methods).

Essential to understand this and also to correctly design the objects in a
program correctly, is this CRC tutorial:
http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/

It's a pity I didn't learn this in college, and had to learn it myself.
Using this method makes for much cleaner OO design then what I did for my
work: often we'd use "getters" and "setters" to manipulate the internal
state of an object (a big NO-NO in OO as you demote objects to glorified
structs).



This is a first step (a good one), but objects are way more than structs.

First of all, objects are like datatypes in the way you assign them to
variables. There the simiilarities with the primitive datatypes end.

The similarity with structs goes a little further: objects contain member
variables. The difference being that structs are just that, and for
objects the (values of the) member variables only define the internal
state.

Objects are more: they are actors. Each method call on an object makes it
_do_ something. What an object does depends on your design.



You are correct in that everything should be an object. C++ doesn't demand
this, but Java does. However, some pieces of code should be in methods in
the same object, while others should be in methods in different objects.
What code belongs where depends on your design.

However, you should never start with code, nor with a flowchart. Instead,
start with what the program should do and what the different parts of the
solution are. Then, use the CRC tutorial I linked to above to decide which
object does what.


Assuming you already found the API documentation and have/are going to
read the CRC tutorial, I have nothing to add. After all, you're already a
programmer and only need to become familiar with the Java API and OO.

Good luck!


Oscar

--
No trees were harmed in creating this message.
However, a large number of electrons were terribly inconvenienced.

Re: Thinking in terms of Objects.

Postby Chris Smith » Mon, 26 Jan 2004 07:00:14 GMT

aveen Reddy wrote:

You may be simultaneously facing two transitions: first, from a
procedural approach to an object-oriented approach; and second, from
scripting tasks to software-development tasks. It's worth, from your
perspective, realizing that object-oriented programming in its popular
forms is intended for software-development kinds of tasks rather than
scripting kinds of tasks.

Of course, both of these generalizations (OO versus procedural, and
scripting versus software-dev) are rather fuzzy, but we're trying to
deal with trends here. In general, OO development differs from
procedural in the way that it ties together the pieces, and software
development differs from scripting by tackling problems that are more
complex by several orders of magnitude.


No, this is way off. Object-oriented language do have such code-blocks,
but they are called methods. (In some OO languages such as C++, they
even popularly go by the name "member functions".) You'd actually be a
lot closer if you compared an class (note the small change from
"object" to "class" there) to a *module* that contains a number of
different functions within one aspect of the application. That's the
first step toward object-oriented programming.

In shell scripting, that's a lot like defining a lot of functions in
another script, and then including that other script so you can refer to
those functions.

Of course, modular programming is everywhere, and the OO apprach
strategy hardly has a corner on that market. OO development does two
things differently from a lot of other "modular" applications.

1. It applies modular programming on a radically smaller scale. Instead
of having modules for each of maybe a dozen parts of an application, a
medium-sized OO project might have about a hundred times that many
classes.

2. It assumes that a logical grouping of similar methods will all
operate on the same data. For example, if your payroll code can do two-
dozen things to employee records, chances are good that these two-dozen
thing are related and should be grouped together in a "module", aka
class.

(It's worth noting that there are a number of situations where #2
doesn't strictly hold, mainly because there may be operations on
employees that belong in a completely different part of the application.
That's okay, and there are idioms and patterns for arranging that. What
matters is that #2 *generally* holds.)


It would be correct to say that *classes* define types of data. (Note
the subtle change from "object" to "class" there.) That's in addition
to classes acting as containers for related "functions" (really
methods), as described above. Hence, the origin of the common platitude
that classes define link state (the data) and behavior (the methods).

As for what *objects* are (as opposed to classes), they are the data and
behavior itself. So a class says that a certain type of object has some
data and can do some things, but it's the object itself that has
specific data and does specific things. So if there your payroll
application is printing out checks for a department with 17 employees,
then your application may contain 17 employee objects, but there is
still only one employee class (the data type and definer of possible
operations on an employee).


Well, polymorphism is *the* fundamental property of objects and object-
oriented systems. You haven't

Re: Thinking in terms of Objects.

Postby Dave Glasser » Mon, 26 Jan 2004 07:04:35 GMT

 XXXX@XXXXX.COM  (Naveen Reddy) wrote on 23 Jan 2004
21:12:58 -0800 in comp.lang.java.programmer:


I think the best way I ever heard it explained was like this:

Computer programs contain state and capabilities. The "state" of a
program is generally it's data, while the "capabilities" are the
things that the program does to or with the data.

With procedural programming languages, like C, the state and
capabilities are pretty much separate and distinct from one another.

In OO programs, an "object" is something that has *both* state (its
member variables, or fields as they're called in Java) and
capabilities (the functions, or methods, that do things with/to the
state of the object.)

It's often said the OO programs allow you to more closely model things
like they are in the real world, because in the real world, objects
tend to have both state and capabilities. Take, for example, a
cassette tape recorder. It can be in various states -- turned off,
turned on, volume up, volume down, etc. -- it has attributes, like
brand, color, model, etc.-- and it can do things, like play a tape,
rewind a tape, erase a tape. This is intuitively understandable to
most people, and that's why, once you grok the basic concepts of OO
programming, it will seem more intuitive and natural than procedural
programming.

(Hat tip to Mike McCarthy.)


-- 
Check out QueryForm, a free, open source, Java/Swing-based
front end for relational databases.

 http://www.**--****.com/ 

Re: Thinking in terms of Objects.

Postby Steve Horsley » Mon, 26 Jan 2004 23:10:38 GMT



I know that I found it hard to get my head round when people tried to 
explain it to me. I think the best teacher that I had was probably the 
java API itself. In writing little utilities, I slowly got to think in 
terms of the objects (File, InputStream, StringTokenizer, Socket) that I 
was regularly using. They are like tools on a workbench - you pick them 
up, use them, put them down.

Then you start to realise that you are creating your own tools or 
objects for ths jobs the standard library doesn't provide, from a simple 
CsvLineSplitter that chops comma separated lines up, to big complex 
object types that are made of lots of smaller object types.

You programming at the design level becomes just a question of 
connecting all the right widgets together in the right way.


I'm not sure if that'll work. You (or at least I can't) cannot think at 
both object level and statement level. They are definitely two different 
levels to my mind. As an example:

You are in the kitchen making a meal, and you need to puree a banana. Do 
you think to yourself "Right, I need to have some sharp metal, moving 
fast, which means I need dome electricity moving round some magnets in 
wires, and some way of making the energy make the sharp metal spin..."?
No! You say "I need a blender". You don't mentally take the blender 
apart or design it from scratch. You don't care if it runs on 
electricity or pixie dust. It's a different mental level.

Steve

Re: Thinking in terms of Objects.

Postby naveen_reddy_2004 » Wed, 28 Jan 2004 09:02:29 GMT

Thanks a lot everybody for your responses and suggestions.
Really appreciate it.

--Reddy

Re: Thinking in terms of Objects.

Postby sgmanohar » Mon, 02 Feb 2004 11:16:13 GMT

teve Horsley < XXXX@XXXXX.COM > wrote in message news:<bv0icv$kju$ XXXX@XXXXX.COM >...

I've always thought the best phrase to explain it was 'data
encapsulation'.
It starts with the assumption that Data, i.e. raw bytes, are
meaningless. To make them Information, i.e. meaningful, you need to
know how to use them.

For example, you could store the state of a light switch as a bit, 0
or 1. In C, just declare "boolean lightState;"
Who is to know whether a 1 means the light is on or off? You need more
than to store a bit in a variable; you need the bit encapsulated in a
Class! You want a method of turning it on and off, and a way of
finding out if it's on.

That is data encapsulation, and to me, it seems, that's what OOP is
about.

Re: Thinking in terms of Objects.

Postby George W. Cherry » Tue, 03 Feb 2004 13:54:29 GMT

"S Manohar" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
news:<bv0icv$kju$ XXXX@XXXXX.COM >...

A good succinct phrase and description. A more verbose
description is that an object is a situation-action machine, that
is, a machine which maps situations (or situation types) onto
appropriate actions.

A situation is a conjunction of facts. For example, here are
some situation-action rules for a bounded stack:

situation1: pop() has been called & the stack contains an item.
action1: return the top item in the stack; move top down by one.

situation2: pop() has been called & the stack is empty.
action2: raise the empty stack exception.

situation3: push(x) has be called & the stack is not full.
action3: move top up by one; store x there.

situation4: push(x) has be called & the stack is full.
action4: raise the empty stack exception.

I call this "Situation-Driven Modeling" (SDM).

George W. Cherry
http://SDM.book.home.comcast.net






Re: Thinking in terms of Objects.

Postby George W. Cherry » Tue, 03 Feb 2004 14:11:02 GMT

"George W. Cherry" < XXXX@XXXXX.COM > wrote in
message news:9KkTb.206675$xy6.1060450@attbi_s02...
am
not
OOPS
I
them
simple
what
the
think
holds.

duhhh. action4: raise the full stack exception.




Re: Thinking in terms of Objects.

Postby paul brown » Tue, 03 Feb 2004 14:51:30 GMT

ere's my 2p while i wait for Websphere MQ to install...

i found it difficult when learning C++ to see where the actual work was
getting done in an OO program.
i would step through code and see loads of indirection and overloading, code
apparently doing very
little, etc...only after perhaps stepping through several classes would i
see the 'meat' of the program,
IO and business logic for example. now i realise a lot of the weird methods
and classes i was looking at
were there to structure the program to make it easier to maintain/extend and
(ironically) easier to understand.
i mean, if you came to the Visitor pattern straight from stepwise refinement
in C, wouldn't you be confused?!

i think a good place to begin is learning about Interface based programming.
the first few chapters of a
COM book, or a Java book (can't name any off hand sorry) would help you
grasp that. i also recommend
you read the 'Gang of Four' Design Patterns book which you can find on
Amazon. (ISBN: 0201633612).
this will show you common class structures you will see when you read Java
code so you'll be able to
grasp the features of a class without having to examine it in minute detail.
this book will also help you
understand the lingo used in a lot of other Java programming books and
articles, etc.

think of objects as black boxes with buttons on. each time you press a
button you change the 'state'
of the object. the way an object responds to a button push depends on what
state it's in - what's happened
to it up to that point in terms of button presses. certain combinations of
button presses cause the object to
exhibit certain behaviour. that list of behaviours and associated button
presses documents the object for its
clients. if you can list all the states an object can be in and how to get
between them, that's brilliant. you
can ideally make concrete assertions about an objects state based on what
button presses have occured
and its documented contract "if you press X, Y and Z in that order, i will
end up in state S1"...if you can
assert the state of all the objects in your system as a program executes,
then you remove the possibilty of some
objects getting into unknown states...when objects get into unknown states
(unknown to you as programmer)
then you have bugs in your system. modelling objects as state machines and
using assertions to check the
states are as you expect is less error prone but requires more effort up
front.

so there are two things to think about. the design time considerations are
structural. what classes comprise
the program, how they are associated.during this phase i personally am
thinking about what is likely to change
in the current solution. what don't i understand yet in this problem? these
areas require most flexibility to change
easily. the runtime considerations are about the states that the objects can
be in and how they interact to implement
a use case.

i think that if a class implementation starts getting complex, break out the
complexities into further abstractions
- use classes to do that, they are your basic tool in Java.

keep classes to under 10 methods if you can...and each one about a page (25
lines) of code...to make each
class readable and comprehendable

study plenty of source code (loads of free stuff on the web-stick to well
known stuff though) be sure to write
Java code on a daily basis...even if its really simple stuff. invent a
little project

Similar Threads:

1.Thinking in terms of Objects.

2.SN#17863 Learn Object-oriented Thinking and Programming with New Java Book

3.problem: what do you think that cache some object in ThreadLocal under j2ee.servlet.struct

Hi All,

In the app, because some DAO layer cache didn't effeciency enough.
I want to give another simple cache in biz layer,
which dedicated to the VO related to big static table (configuration).

I have 3 residence of cache obj,  memory, ThreadLocal, Session.

because in our app, this cached configuration is site layer ,
and Session is based on user, i.e. every logined user have a session.
i didn't require store the sample site configuration for every user,
so i discard the session choice temporarily here.

what do you think about cache in ThreadLocal,
some problem exist? what will you concern if you do this?

any ideas & argument welcome.

tks
sods


4.If you think you must modify the hash, think again

5.Linear thinking vs essential thinking

In profiling it is typical that some few lines of the code take a major part 
of the total execution time.
Graphically like this( letters a program part names, numbers time consumed 
in time units) :

A: 0000000000 1111111111 2222222222 3333333333 4444444444 555555555 666
B: 0000000000 1111111111 2222222
C: 0000000000 1
D: 000
E: 00
F: 0
G: 0
H: 0
I:
J:
K:
L:
M:
N:

If one tries to reduce to execution time it is useful to concentrate to A, 
and perhaps to B, C  but
forget D..N totally.

This is probably a trivial fact for every reader when talking about program 
execution time or memory usage.

But what about learning javascript, is there also this kind of phenomenon?

Some people seem to think linearly all the time: proceed pedantically from A 
to N (or from N to A ), devoting as much time and attention to all the 
items. For them there is no intermediate possibility: either one has know 
thoroughly every item A, B,...N, or none.

Knowing A, B, C well and knowing very little or hardly anything about D..N 
is very difficult to imagine for them. To change the attitudes, point of 
views, or even imagine others to have different point of views is almost 
impossible for them.

Of course, if one has much time in one's disposal, e.g. 10 years of full 
time job in javascript and additional hobby time, one has learnt all the 
items A...N thoroughly.

If one tries to simply express some rule of thumb or recommendation about 
javascript here, e.g. about passing objects to functions , the discussion 
goes from the essential A to random parts in K or L, and after a while a 
non-expert has not any good idea, how things are. Or a simple, clear, easy 
to understand and maintain example is rejected on the basis that it might 
waste some microseconds during the whole lifetime of the program. Sigh.

If one tries to learn a new natural language, it is sensible to learn some 
frequently used things first and not wait some years first to open one's 
mouth publicly.

I would like to see the same to happen here: pedagocically correct approach, 
concentrating to the essential things.  Linear thinking has its advantages 
at the most advanced level, but in learning it is better to simplify things.











6. Java SSH Term and SSH vnc Term available at my website!

7. Long Term Encryption

8. Long term Consulting Assignment?



Return to JAVA

 

Who is online

Users browsing this forum: No registered users and 20 guest