Thinking in terms of Objects.

java-programmer, Thinking in terms of Objects. 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

java-programmer >> Thinking in terms of Objects. Check this free book out: Thinking in Java, 3rd ed. Revision 4.0 at
http://www.mindview.net/Books/TIJ/

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

"Naveen Reddy" <email***@***.com> wrote in message
news:email***@***.com...
> 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
>

java-programmer >> Thinking in terms of Objects. 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

java-programmer >> Thinking in terms of Objects. 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 nakedobjects @ www.nakeobjects.org;
there's some really nifty OO-based tools and other resources to be had
there, too.

Naveen Reddy wrote:

> 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.
>

java-programmer >> Thinking in terms of Objects. Naveen Reddy wrote:
> 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?

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.

> 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.

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".

>
> 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.

No. Not really.

> 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?

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'.

>
> 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.

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)...

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

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

java-programmer >> Thinking in terms of Objects. In comp.lang.java.help Naveen Reddy <email***@***.com> wrote:
[A C coder learning OOP]
>
> 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.

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).

> 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?

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.

> 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.

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.

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

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.

java-programmer >> Thinking in terms of Objects. Naveen Reddy wrote:
> I come from a background of Unix C-shell, WIN .bat programming and am
> entirely new to the concepts of Object-Oriented programming.

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.

> 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.

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.)

> 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.

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).

> 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?

Well, polymorphism is *the* fundamental property of objects and object-
oriented systems. You haven't gotten there yet, though. See if the
above makes sense, and then I'll move on.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

java-programmer >> Thinking in terms of Objects. email***@***.com (Naveen Reddy) wrote on 23 Jan 2004
21:12:58 -0800 in comp.lang.java.programmer:

>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 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://qform.sourceforge.net

java-programmer >> Thinking in terms of Objects. Naveen Reddy wrote:
> 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?
>

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.

> 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.

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

java-programmer >> Thinking in terms of Objects. "Oscar Kind" <email***@***.com> wrote in message
news:40124e9b$0$135$email***@***.com...
> In comp.lang.java.help Naveen Reddy <email***@***.com> wrote:
> [A C coder learning OOP]
> 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/
>

Though I haven't taken an in-depth look, I was put off almost immediately
when I go the impression I was looking at a real estate course "Think in an
Object Oriented manor." Made me think I was going to have to buy a new house
before I could do OOAD.

I will "give it a chance" though.

- Virgil

java-programmer >> Thinking in terms of Objects. Thanks a lot everybody for your responses and suggestions.
Really appreciate it.

--Reddy

java-programmer >> Thinking in terms of Objects. Steve Horsley <email***@***.com> wrote in message news:<bv0icv$kju$email***@***.com>...
> Naveen Reddy wrote:
> > 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?
> >
>
> 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.
>
> > 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.
>

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.

java-programmer >> Thinking in terms of Objects.
"S Manohar" <email***@***.com> wrote in message
news:email***@***.com...
> Steve Horsley <email***@***.com> wrote in message
news:<bv0icv$kju$email***@***.com>...
> > Naveen Reddy wrote:
> > > 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?
> > >
> >
> > 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.
> >
> > > 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.
> >
>
> 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.

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

java-programmer >> Thinking in terms of Objects.
"George W. Cherry" <email***@***.com> wrote in
message news:9KkTb.206675$xy6.1060450@attbi_s02...
>
> "S Manohar" <email***@***.com> wrote in message
> news:email***@***.com...
> > Steve Horsley <email***@***.com> wrote in message
> news:<bv0icv$kju$email***@***.com>...
> > > Naveen Reddy wrote:
> > > > 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?
> > > >
> > >
> > > 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.
> > >
> > > > 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.
> > >
> >
> > 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.
>
> 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.

duhhh. action4: raise the full stack exception.

> I call this "Situation-Driven Modeling" (SDM).
>
> George W. Cherry
> http://SDM.book.home.comcast.net
>
>
>
>
>

java-programmer >> Thinking in terms of Objects. Here'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 for yourself and work away at it
during your spare time.

last of all, don't forget all the good stuff you have learnt already.
objects aren't the be-all-and-end-all.

hope this helps,
paul

"Naveen Reddy" <email***@***.com> wrote in message
news:email***@***.com...
> 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