OOP, what is an Object?

[Maurizio Gasparro]

Hi guys, as you can easily understand, I'm a real greenhorn in programming, so I'm really sorry if this question is too silly for you.
I've just started studying Java and to be honest I'm still a bit confused about the OOP concept.
So, a Class is a container of Methods and Objects like in the following example:

public class TableAndChairs 
{
	public static void main(String[] args)
	{
		System.out.println("x                      x");
		System.out.println("x                      x");
		System.out.println("x      xxxxxxxxxx      x");
		System.out.println("xxxxx  x        x  xxxxx");
		System.out.println("x   x  x        x  x   x");
		System.out.println("x   x  x        x  x   x");
		System.out.println("x   x  x        x  x   x");
	}

}

now, I know that

main(String[] args)

is the "main" Method of the Class and then I can create other Methods within or outside the Class and use them whenever I need them.
That's fine, I've got it! (I think...)

But then there are statements (which in this case are also Methods of a class but let's forget about this for a moment) like these:

System.out.println("x                      x");

that are part of the Method body.

That said guys, my question is: what are Objects? How do I identify/recognise an Object? I am very confused to be honest...
Probably I'm going too fast and I will understand later in the book what they are, but for now, if anyone asks me the question my answer would be: I don't have ideat!

Can please anyone shed some light on it and help me understand?

Thank you very much in advance for your precious help, I hope one day I will be able to help people in this forum ;-)

[S Fox]

Every "thing" can be an object. If you made a class to represent a table and chairs, then when you instantiate it you have created a new object.

// creates a new instance of this object
TableAndChairs t = new TableAndChairs();

even though the class can contain methods in it, it's still considered an object.
Integer is a type, but if you instantiated one of those it becomes an object too, any time you use the keyword "new" you are making a new object.

[S Fox]

Another important thing to know right away is that with some declarations in java they have made it where you don't need to write the word new.
It still is creating a new object instance, but for convenience they got rid of the requirement to write it.

Integer x = 6;
Integer y = new Integer(6);

String a = "hello";
String b = new String("hello");

Also you need to know, when you make a new object you have to assign it to a variable to keep using it, it creates a pointer from the variable to the object.
I think in java it's called a reference, not a pointer. In every other language I know of though it's called a pointer. it's pointing to the memory address where the object is stored.

new Integer(6);
this does create a new object, but you can never use it again, it's lost forever. since you didn't assign a variable.
you can "point" the same variable at a different object, by doing a new assignment.

changing the value of a variable sometimes creates a whole new object, because some objects are immutable. immutable objects aren't allowed to be modified.
that means they just throw the old object in the trash and give you a whole new one when you do try to change the value of it.

I think in java if you assign the exact same value to a String on two different variables, it will point both to the exact same address in memory, because java has a string pool.
I'm not 100% sure about this one anymore.

[Harry Kar]

Maurizio Gasparro wrote:Hi guys, as you can easily understand, I'm a real greenhorn in programming, so I'm really sorry if this question is too silly for you.

Ciao Maurizio and welcome! don't be sorry you're not alone in facing such questions at a certain point in time. You don't know but you're lucky to be a  greenhorn in programming when you start OOP. People accustomed  in other styles e.g. procedural find harder to tackle with OOP ;)

 

I've just started studying Java and to be honest I'm still a bit confused about the OOP concept.
So, a Class is a container of Methods and Objects like in the following example:

public class TableAndChairs 
{
	public static void main(String[] args)
	{
		System.out.println("x                      x");
		System.out.println("x                      x");
		System.out.println("x      xxxxxxxxxx      x");
		System.out.println("xxxxx  x        x  xxxxx");
		System.out.println("x   x  x        x  x   x");
		System.out.println("x   x  x        x  x   x");
		System.out.println("x   x  x        x  x   x");
	}
}

)

Before examine the class as a container/module that contains methods and fields (and other things too) at an implementation level let's firstly go back a step in a more abstract level and say that a class is like a blueprint/template that describes the properties and behaviours of an object in the real world. That's the real work of a class.
In other words we try to model (in software) a thing for example a person in the real world trough a software artifact  i.e. class  Person like that

 public class Person {
   // here goes the modelled properties and behaviours of the Person
}

Now a person has some attributes(translates as fields in the class) such an age for example and behaviours(translate as methods in the class) too such as beAngry.
Let's put those ingredients into our class

public class Person {
  private int age;

  public void beAngry() {
      System.out.println("Grr..")
  }

  public int getAge() {
     return age;
  }

}

Actually a person  in the real world has more many attributes and behaviours but we do not describe all those in all of our programs where a person is needed; we describe only a very small part of them depend on what of them are important(have the focus) in our application; for example in a bank probably are considered the
firstName, lastName, SSN, etc but not the eye's color of  a person;
After all a model to be useful in some manner have to be simpler than the reality/original it represent.  
That technique is called Abstraction and is very important in programming in general and moreover in Object Oriented programming.

For now let's abstract the precise meaning of private public modifiers  in the class and method headers and say (for the sake of simplicity here and good OOP practices) that all fields have to be private and all methods have to be public

Why we bother about all that classes - objects and the like stuff?  
Because is demonstrated that help us tackle with complex software(here you go to software engineering field). If you have to write few tenths, hundreds or thousands lines of code to solve a problem and then scrap the code out that's no big deal to use OOP but what if you(ans your team) have to write hundreds of thousands, milions lines of code to solve a complex problem and have to maintain that code for some decades? As you can understand here things and moreover costs are totally different

As we did for Person in your problem domain surely have to be other entities to  model and you go on to model that entities trough classes.
All in all till now a problem in the real world is reduced/modeled as a set of related (to the problem) classes ok? Every class has it's own fields and methods and represent an entity in the problem  domain

now, I know that

main(String[] args)

is the "main" Method of the Class and then I can create other Methods within or outside the Class and use them whenever I need them.
That's fine, I've got it! (I think...) )

Right of all the classes you have to decide what class is your main class and put there your {public static} main method that is the entry point in a Java application(and in a C like application too)

But then there are statements (which in this case are also Methods of a class but let's forget about this for a moment) like these:

System.out.println("x                      x");

that are part of the Method body.

Let's take it from start
One time code was macaroni style mean a bunch of statement(command) lines without any structure;  as time goes on people understand that was necessary a bit of organization so people taken a set of related statements and gave them a name and formed the first reusable programming unit and called it function or procedure or subroutine(the terms indicate some difference but for now let's abstract  about that). In java a function/procedure/subroutine  is called method
People enjoyed because

can subdivide/organize their problems in terms of functions and

when the same bunch of code is needed in more parts of the same program they can use merely the function identifier(name)  instead of copy past the bunch of code(the function identifier represent)  anywhere in the code

If the bunch of code change because the requirements change you have to do changes in one place instead of throughout all the code  

well written functions now can be reusable in other programs too

that was the time of procedural abstraction

After that phase of structured procedural programming comes OOP in which the focus is on objects that is the principal module/unit and contains data(fields) and functions(methods) that operates on those data. So an object became a complete(in the sense that contains data + operations on that data) organizational unit
 

That said guys, my question is: what are Objects? How do I identify/recognise an Object? I am very confused to be honest...

Till now we saw what are classes but for what are useful to us? Imagine classes as fabrics (they're static things) from where we fabric objects(called also class's instances).
Objects are our hard workers  (active things) all the work is accomplished from objects not from classes.
The class is the blueprint from which objects are generated.
All objects of the same class share the same behaviour(methods) and set of fields(called also state) as their class dictate/state.
But each object  of the same class have  distinct state(the field values differ)
Each object  of the same class has a distinct identity(given by the system).Imagine two objects of the same class with the same state(field values). Are they the same thing? no they are still distinct

Generate an object mauri from a class Person

Person mauri = new Person();  

 
Once an object is generated you can forget the class concept and start work on that object . How?

In our application as we mention we have  more than one classes so consequently we have more than one type(note that the class denotes also a type for the object) of objects too. So till now we've transformed our problem in a set of objects that communicate with each other contributing to solve the problem

How communicate objects with each other?
By sending messages(called also invoking/calling/activating methods). What that means is:
an object objA (in his body) )call a method defined in(to the body of) an object objB such as:   objB.methodInB

e.g.

System.out.println("x      xxxxxxxxxx      x");

Here the println method is invoked on the System.out object. Here the println() is a static/class method,  mean the method is "sticked" in class is part of the class or is  shared to all the istances of the class. the method is not part of the object    

Here the getAge() is invoked on mauri object and the value is then assigned to mauriAge int variable. In that case  getAge() is an instance method mean is part of every instance of the class  

int mauriAge = mauri.getAge();

Probably I'm going too fast and I will understand later in the book what they are, but for now, if anyone asks me the question my answer would be: I don't have ideat!

Can please anyone shed some light on it and help me understand?

Thank you very much in advance for your precious help, I hope one day I will be able to help people in this forum ;-)

What text are you using? i warmly recommend you also one OOP centric that use BlueJ (that one is awesome especially in an early phase of learning ) such as
Objects First with Java
by David J. Barnes, Michael Koelling
https://www.goodreads.com/book/show/14795496-objects-first-with-java?ac=1&from_search=true

Cheers
Harry G.T. Kar

[Harry Kar]

How do I identify/recognise an Object?

In code written under the Sun recommendations is trivial follow the first letter of the object(or class) the method is invoked
If is lowcase then you have to do with an object(instance of a class) e.g. in mauri.getAge getAge is invoked on mauri (start with lowcase m --> mauri is an oject)
if instead is uppercase  you have to do with a class e.g. in System.out.print("Hello") print is invoked on System.out (start with uppercase S  --> System is a class)

[Maurizio Gasparro]

Thank you very much to both S Fox and Harry Kar, your help is much appreciated.
Well, after your replies it is definitely clearer than before, it is not very easy to understand at the beginning because some terms get "overlapped" liked Method/Function etc...

Thank you again!
Maurizio

[Maurizio Gasparro]

Sorry Harry, I didn't reply your question: I'm studying with the book Programming Java 8th edition by Joyce Farrel
To be honest I find it fairly good for my level (beginner).

[Junilu Lacar]

A class is a general description of a set of capabilities and attributes. For example, if you were asked to describe what a Person is capable of doing and what kind of information about a Person might be interesting to know, you might say something like "Well, a Person has a name, and they can say their name. A Person can also be told to talk, listen, sleep, run, walk, and do some work."  This is basically what you're saying when you write code like this:

public class Person {
    private String name;

    public Person(String name) {
         this.name = name;
    }

    public void sayName() {
         System.out.println("My name is " + name);
    }

    public void talk() { ... }

    public void listen() { ... }

    public void sleep() { ... }
 
    public void run() { ... }

    public void walk() { ... }

    public void work() { ... }
}

The Person description is distinct from the things that are being described, which are actual people. That is, you are an example (an instance) of a Person just as I am another example (another instance) of a Person. It's also probably safe to assume that everyone who has contributed to this thread and other threads at the Ranch are also Persons (people). The description of Person, however, is not a Person. It is a description.  Likewise, the code above is a description of what a Person object can do and the information each instance of Person would have. We, on the other hand, are instances. In code, that would be something like this:

     Person me = new Person("Junilu");
     Person mo = new Person("Maurizio");
     Person harry = new Person("Harry Kar");

     me.sayName();  // prints "Junilu"
     me.talk();

     mo.sayName();  // prints "Maurizio"
     mo.listen();

     harry.sayName();  // prints "Harry Kar"
     harry.run();

In the above code, you are creating three instances of the Person class. Each instance is an object. The variables me, mo, and harry are each references to one of those objects, respectively. Since those references allow you to manipulate the objects they are associated with, we often use the mental shortcut of treating me, mo, and harry as the objects themselves instead of just being distinct "handles" that allow you to access the actual objects and manipulate them in whatever ways they are designed to be manipulated.

This is probably why Harry said that if you see a name that starts with a lowercase letter, that's an object. In most cases, like in the code above, that's going to be true. That's just a convention though and you have to remember that not all Java code will follow this convention. The convention is not enforced by the language. It's just a matter of choice by the author whether they want to follow convention or not. So, don't rely on the convention to distinguish between a class and an object. Understand the fundamental difference instead. (However, please be kind to other people who will read your code and follow the conventions)

[Harry Kar]

Maurizio Gasparro wrote:Sorry Harry, I didn't reply your question: I'm studying with the book Programming Java 8th edition by Joyce Farrel
To be honest I find it fairly good for my level (beginner).

Yeah i know it and quote it's a very good test.
Fortunately out there exist a wealth of beginner text books  on the subject but few of them are special (in argument's exposition etc) like the one i propose you earlier(that primarily use Java as tool to explain OOP and not teach Java itself)  that also use  BlueJ that is a specific environment for teaching and learning especially useful  at a start-medium leve le.g.conversely to other "traditional" environments trough  BlueJ  is manifest the difference class - object

I know the acceptance of a text is a personal thing but if you have a biblio near you take a glance

[Harry Kar]

Was a good thing for forgetters like me if posts here were editable

I forgot to mention  a non code - centric(but instead conceptual - centric) text on OOP that fits well for beginners too(for best profit read/studying it in parallel with your main text )  
The Object-Oriented Thought Process, by Matt Weisfeld

[Knute Snortum]

Harry Kar wrote:Was a good thing for forgetters like me if posts here were editable

There's some good reasons why you can't edit posts, but instead of getting into those, let me encourage you to do these:

* Use the Preview button, just to the left of the Submit button
* There's nothing wrong with making a second post (as you did) saying, "Oh, I forgot something..."

[Harry Kar]

@ Maurizio Gasparro
Despite the fact that Junilu described it very well with few lines of code here are some other alternative description  from The Object-Oriented Thought Process, by Matt Weisfeld

[Harry Kar]

Knute Snortum wrote:

Harry Kar wrote:Was a good thing for forgetters like me if posts here were editable

There's some good reasons why you can't edit posts,

Some useful link to get an idea ?

but instead of getting into those, let me encourage you to do these:

* Use the Preview button, just to the left of the Submit button
* There's nothing wrong with making a second post (as you did) saying, "Oh, I forgot something..."

Thanks Knute i try to remember to press Preview more often

[Knute Snortum]

Harry Kar wrote:

Knute Snortum wrote:

Harry Kar wrote:Was a good thing for forgetters like me if posts here were editable

There's some good reasons why you can't edit posts,

Some useful link to get an idea ?

I think the whole thread below is useful but Liutauras's post especially:

https://coderanch.com/t/683892/Request-removing-Editing-restrictions#3209445

[Harry Kar]

S Fox wrote:
.....
I think in java if you assign the exact same value to a String on two different variables, it will point both to the exact same address in memory, because java has a string pool.
I'm not 100% sure about this one anymore.

That's correct below s1 and s2 reference the same object/instance or if you prefer the object is aliased by two identifiers s1 and s2

String s1 = "Howdy?";
String s2 = "Howdy?";

On the other hand  using the new operator that's not true; with new you create ever new instances; so  the two strings below are distinct objects/instances

String s1 = new String("Howdy?");
String s2 = new String("Howdy?");

[Al Hobbs]

I think it's good to just think of objects like a set of code that is separated from the main code so that you can use it later.

In your post you had a program that printed out two chairs and a table.  If you were to make that into objects you could have an object that would print from a string, list, or a file and then instead of having a program that prints only chairs and tables, you'd have a program that can print whatever text you give it.

[daniel jaimini]

In simple terms, you can access methods and data of classes using objects

[Nathan Milota]

An object is something we told kids to keep to themselves when I worked at a preschool.

[Junilu Lacar]

Al Hobbs wrote:I think it's good to just think of objects like a set of code that is separated from the main code so that you can use it later.

This alludes to encapsulation and reuse, which are fine in and of themselves. However, in the context of the question about the difference between a class versus an object, I don't find it particularly useful.

[Junilu Lacar]

Welcome to the Ranch, Daniel Jaimini!

daniel jaimini wrote:In simple terms, you can access methods and data of classes using objects

That doesn't sound right. A class defines what methods and attributes/data an object can have. You can also have methods and data associated with a class itself. You don't need an object to access those. Instead, you access them directly through the class itself.

[Nathan Milota]

The word object in object oriented programming makes as much sense as the world thing in the English language.  Basically, you have a class, and then you have an object which takes all the variables of that class.  An Airplane class can have a b17 object, a 707 object, etc.

[Harry Kar]

daniel jaimini wrote:In simple terms, ...

Daniel i know the OO lingo can confuse especially if one is a primer cause the use of ,ore than one synonyms for the same concept as pointed out from Maurizio Gasparro few posts earlier

...
it is not very easy to understand at the beginning because some terms get "overlapped" liked Method/Function etc...

 

but all of us have passed that phase and is necessary learn the lingo if you want to can be understood from others who speak the same lingo too

you can access methods and data of classes using objects

Yes you can use the dot operator with prefix an object/instance of a class if the method/message is an instance method(immagine it as  sticked with each object). The general form is:

objectIdentifier.instanceMethod([optional actual parameters/arguments separated by comma if more than one])

As pointed out from Junilu if instead the method is a class/static method  It's not necessary(but you can if you want, though that's not the right way to do it) create an object to invoke the static method on the object; Instead in that case you have to use the Class identifier(name) as a prefix to the method.  The general form is:

ClassIdentifier.staticMethod([optional actual parameters/arguments separated by comma if more than one])

[Harry Kar]

Kenneth Milota wrote:The word object in object oriented programming makes as much sense as the world thing in the English language.  Basically, you have a class, and then you have an object which takes all the variables of that class.  An Airplane class can have a b17 object, a 707 object, etc.

I am not a native Fnglish but i think you guessed it right. Beware only that the object takes not only variables(fields in Java lingo) but functions(methods in Java lingo) too.

Other that don't forget also that here we have two types of variables (fields in Java lingo) and methods  :
Methods and variables that are not declared as static are known as instance methods and instance variables.
Methods and variables that are  declared as static are known as static/class methods and static/class variables
the difference between the two is:
To refer to instance methods and variables, you must instantiate the class first means you should create an object of that class first.
For static you don't need to instantiate the class you can access the methods and variables with the class name using period/dot sign (.)

a) instance fields + instance methods
a.1) either exist in every object generated from a class;
a.2) the values of the instance variables can be the same or (usually) different on different objects of the same class;  
a.3) viewed  all together as a set those values set is called state of the object
a.3) instead the set of the methods is called behaviour of the object
a.4) differently from the state of each object that can vary from object to object the behaviour of each object of the same class can't vary/changed and that's valid for all the class's objects

b) Class fields + Class methods
b.1) either of them exist only "in a unique copy" sticked in a class and that "one copy" shared by all objects of the class
b.1) differently than in case a) where every object "owns" independently his own copy of instance fields + instance methods in case b) exist only one copy of Class fields + Class methods for all class's objects. Means  that all the objects of a class have/share the same value stored in a Class field instead of every object having his  distinct copy of value
b.2) Static methods can’t access instance methods and instance variables directly(because the later needs an object to be instantiated before). On the other hand Instance methods can access static variables and static methods directly.
b.3) Static methods and fields is declared with static keyword. Instance methods  and fields aren't with static keyword.

I tried to expose it in a "handy" manner  hope this helps

[daniel jaimini]

Junilu Lacar wrote:Welcome to the Ranch, Daniel Jaimini!

daniel jaimini wrote:In simple terms, you can access methods and data of classes using objects

That doesn't sound right. A class defines what methods and attributes/data an object can have. You can also have methods and data associated with a class itself. You don't need an object to access those. Instead, you access them directly through the class itself.

Are you talking about static members of classes?

[Harry Kar]

daniel jaimini wrote:

Junilu Lacar wrote:Welcome to the Ranch, Daniel Jaimini!

daniel jaimini wrote:In simple terms, you can access methods and data of classes using objects

That doesn't sound right. A class defines what methods and attributes/data an object can have. You can also have methods and data associated with a class itself. You don't need an object to access those. Instead, you access them directly through the class itself.

Are you talking about static members of classes?

I'm not Junilu but obviously yes, from the context it's clear here's  no other options one class member can be  either static or not static; on purpose in case for a refresh take a glance  here

[Harry Kar]

A few principles about objects can be helpful :

1. It’s the objects that matter, not the classes
It's important point  to understand how objects behave at runtime, how they interact, and how they provide services to each other.
Classes are not as flexible as objects; they are merely development-time blueprints and a technical necessity for creating objects.
We have to learn think in terms of objects
NOTE
       Indeed, not all OO languages have classes. OO languages such as Java  C++, C#, and Smalltalk are class-based.
       In them each object is an instance of a class fixed at creation time. Conversely in  object-based languages, such as
      JavaScript, objects are lightweight containers for methods and fields. Methods can even be changed for
       individual objects.

2. An application is an interconnected set of collaborating objects.
The idea of many small objects solving the application’s task together is perhaps the central notion of object-oriented programming.
While in procedural programming a few hundred modules have the responsibility to provide the functionality, in object-oriented
applications a few hundred thousand objects can share and distribute the load.

3. Objects are small, active, black-box entities.
When many objects solve a task together, each object can focus on an only a small aspect and can therefore remain small and
understandable: It contains just the code and information relating only to that particular aspect. To achieve a clear code structure,
it is helpful to adopt as many helper objects as you like.

Objects are handled by reference i.e. passing objects around means copying pointers, which are mere object's memory locations.

Objects are active things . While modules and data structures in classical procedural programming(data are on their own and functions
--that operate on the data-- are on their own too) primarily have things done to them by other modules, objects are best perceived as
doing things(because other than data/fields contains also code/methods that operate  on that data). For example, a Button does not
simply paint a clickable area on the  screen; it also shows visual feedback  when the user clicks the button.

Objects are “black-box” items. Although they usually contain some extensive machinery necessary for performing their task, there is a
invisible protective box around the object that other objects do not penetrate. e.g. Assume Object B employs several helper objects, of
which one of those say C implements some functionality m that another object A requires. Since B is a black box(don't publish his internal
structure.), A should not make assumptions about its internal structure and cannot call on C directly(because is hidden in  black box C).
Instead, A sends B a message m; that is, it calls its method m. Unknown to A, m now calls on C.
That's how objects communicate each other

4. Objects are team players not lone snipers
For  objects working together requires lean public interfaces: Delegating tasks works well only if the other object states succinctly and precisely
what functionality/behaviour(set of methods) can provide.

5. Objects have an identity.
Except in the case of value objects, one cannot simply exchange one object for another, even if they happen to store the same data in their fields.

6. Objects have state.
Objects store data in their fields and—apart from a few special cases e.g. constants— that data(state) changes over time.

7. Objects have a defined life cycle.
An object is declared, instantiated, used (from the outside trough his method calls ), assigned   and finally when not needed more destructed from the garbage
collector. That's his life cycle

[Harry Kar]

Harry Kar wrote:

S Fox wrote:
.....
I think in java if you assign the exact same value to a String on two different variables, it will point both to the exact same address in memory, because java has a string pool.
I'm not 100% sure about this one anymore.

That's correct below s1 and s2 reference the same object/instance or if you prefer the object is aliased by two identifiers s1 and s2

String s1 = "Howdy?";
String s2 = "Howdy?";

On the other hand  using the new operator that's not true; with new you create ever new instances; so  the two strings below are distinct objects/instances

String s1 = new String("Howdy?");
String s2 = new String("Howdy?");

Quite casually browsing here and there in coderanch i found an extensive and very good explanation Strings, Literally by Corey McGlone that worth reading

[Campbell Ritchie]

Harry Kar wrote:. . .
a) instance fields + instance methods
a.1) either exist in every object generated from a class;
. . .

Not quite. There is no point in having multiple copies of a method; they would be mutually identical. One copy of each method is stored in the Class<T> object corresponding to each instance. Other languages might use differennt implementation techniques.

[Harry Kar]

Harry Kar wrote:  For now let's abstract the precise meaning of private public modifiers  in the class and method headers and say (for the sake of simplicity here and good OOP practices) that all fields have to be private and all methods have to be public

Object's fields represent the object's knowledge base on which object's methods have substance to operate to carry out the object's final working target  as designed from his designer
From a bird's eye perspective of the overall system, however, this  knowledge base of an object is a private, hidden detail(think it as a private property). Consequently, other objects must not make any assumptions about which fields exist and what they contain.

The first OO language i.e. Smalltalk takes this aspect very seriously: Only the object itself can access its fields (including those inherited from its superclass); field access across objects is impossible.

In Java instead, an object can access
1. private fields of other instances of its own class,
2. protected fields can be accessed from all subclasses(regardless of the package they're declared) and classes in the same package,
3. and default visible fields (without modifiers) are shared within the package.
4. public fields are even open to the entire world.

While all fields, technically speaking, store mere data, their usage differentiates between various intentions and interpretations associated with that data. Anticipating these intentions often helps in understanding the fields of a concrete object and their implied interdependencies. Notice also that an object’s fields last for the entire object's lifetime.
Fields are initialized when the object is created by the constructor. Afterward, they retain their meaning until the object is picked up by the garbage collector.
At each point in time, we should be able to say what each field contains and how it relates to the other fields. In consequence, we should refrain from “reusing” fields for different kinds
of data, even if the type fits. It is far better to use a second field.
Also, we should avoid having fields that are valid only temporarily, and prefer to introduce helper objects.

[Harry Kar]

Campbell Ritchie wrote:

Harry Kar wrote:. . .
a) instance fields + instance methods
a.1) either exist in every object generated from a class;
. . .

Not quite. There is no point in having multiple copies of a method; they would be mutually identical. One copy of each method is stored in the Class<T> object corresponding to each instance. Other languages might use different implementation techniques.

Ok you're right but that's an implementation detail actually, all that matters(conceptually) is that, to a user of an object the methods are stored as if they were stored separately in every object (i can't find a better way to expose it better without enter in implementation details)
In the same shape as when we say
An array is a collection of elements, of the same type, that are stored contiguously in memory. Contiguous means the individual elements are stored next to each other.
Actually, all that matters is that, to a user of an array, the elements are stored as if they were contiguous.

[Campbell Ritchie]

It only matters to a user that the correct method can be found from an object reference.

[Campbell Ritchie]

Harry Kar wrote:. . .
The first OO language i.e. Smalltalk takes this aspect very seriously: Only the object itself can access its fields (including those inherited from its superclass); field access across objects is impossible.
. . .

That sounds a good idea; it is like making all fields private regardless, and more. But Smalltalk was preceded by Simula‑67 five years earlier.

[Harry Kar]

Simply awesome:
Alan Kay’s( he's one of the authors of Smalltalk he also  coined the term “object-oriented.” ) concept of objects: being similar to biological cells that send each other messages.

[Harry Kar]

Campbell Ritchie wrote: ... But Smalltalk was preceded by Simula‑67 five years earlier.

Right but if i remember well Smalltalk is the first OOL with wide acceptance in practice the first mainstream OO language

[Harry Kar]

Campbell Ritchie wrote:

Harry Kar wrote:. . .
The first OO language i.e. Smalltalk takes this aspect very seriously: Only the object itself can access its fields (including those inherited from its superclass); field access across objects is impossible.
. . .

That sounds a good idea; it is like making all fields private regardless, and more.....

Agree
Smalltalk is a pure OO language(everything is an object Vs primitive and reference Java's types) and has stricter encapsulation than Java. Object's fields can be accessed  only through messages. Java instead  is more flexible/lascivious allows also public,protected, default/package visibility fields.

[Junilu Lacar]

Harry Kar wrote:Java instead  is more flexible/lascivious

I'm not sure what you meant to write but I'm sure it wasn't "lascivious"  

[Harry Kar]

Junilu Lacar wrote:

Harry Kar wrote:Java instead  is more flexible/lascivious

I'm not sure what you meant to write but I'm sure it wasn't "lascivious"  

ROFTL sometimes the spell checker here  becomes furious ; what i meant is: relaxed

[Harry Kar]

Thinking more profoundly maybe the potential confusion about class and object  has to do with the very nature of the software itself.
Software is different from products in all other engineering disciplines. For example rather than delivering a final product, delivery of software means delivering the "blueprints for products". Imagine computers as fully automatic factories that accept such blueprints and instantiate them. Normally a computer can instantiate delivered software as often as required.
The most  distinctive aspect of software is that it's  a "metaproduct". Are these metaproducts that are actually deployed when we acquiring software.
It is as important to distinguish between software and its instances as it is to distinguish between blueprints and products, between plans and a building, between beings and their genes (phenotypes and genotypes) etc. Whereas such lines are clearly drawn in other engineering disciplines, software seems too “soft” on that aspect.

So the confusion between objects and classes is closely related to the "soft" nature of software; e.g. both the plan of a building and the building itself can be modeled as objects. At the same time, the plan is the “class” of the building. There is nothing wrong with this, as long as the two kinds of objects are kept apart. In the world of logic, and possibly other disciplines  this is called stratification – i.e. introduction and maintenance of strata or levels of organization. Construction (and breach) of such layers has to be based on deep understanding.

[Campbell Ritchie]

Harry Kar wrote:. . . Software is different from products in all other engineering disciplines.

Please explain more. Simply having something tangible as opposed to something intangible doesn't mean that software creation differs fundamentally from designing something tangible.

For example rather than delivering a final product, delivery of software means delivering the "blueprints for products". . . .

I am not convinced about that. What you are delivering is a tool, which simply has to be used. The software is the finished product, which simply has to be turned on. It no more needs instantiation than a circular saw would need instantiation; it simply needs to be put into position. If the tool happens to make something else, that doesn't constitute instantiating that software.

. . . "metaproduct". . . .

What's a metaproduct? It doesn't clarify anything for you to coin words which nobody is familiar with.