Whats the difference between objects and data structures?

The distinction between data structures and classes/objects is a harder to explain in Java than in C++. In C, there are no classes, only data structures, that are nothing more than "containers" of typed and named fields. C++ inherited these "structs", so you can have both "classic" data structures and "real objects".

In Java, you can "emulate" C-style data structures using classes that have no methods and only public fields:

public class VehicleStruct{    public Engine engine;    public Wheel[] wheels;}

A user of VehicleStruct knows about the parts a vehicle is made of, and can directly interact with these parts. Behavior, i.e. functions, have to be defined outside of the class. That's why it is easy to change behavior: Adding new functions won't require existing code to change. Changing data, on the other hand, requires changes in virtually every function interacting with VehicleStruct. It violates encapsulation!

The idea behind OOP is to hide the data and expose behavior instead. It focuses on what you can do with a vehicle without having to know if it has engine or how many wheels are installed:

public class Vehicle{    private Details hidden;    public void startEngine() { ... }    public void shiftInto(int gear) { ... }    public void accelerate(double amount) { ... }    public void brake(double amount) { ... }}

Notice how the Vehicle could be a motorcycle, a car, a truck, or a tank -- you don't need to know the details. Changing data is easy -- nobody outside the class knows about data so no user of the class needs to be changed. Changing behavior is difficult: All subclasses must be adjusted when a new (abstract) function is added to the class.

Now, following the "rules of encapsulation", you could understand hiding the data as simply making the fields private and adding accessor methods to VehicleStruct:

public class VehicleStruct{    private Engine engine;    private Wheel[] wheels;    public Engine getEngine() { return engine; }    public Wheel[] getWheels() { return wheels; }}

In his book, Uncle Bob argues that by doing this, you still have a data structure and not an object. You are still just modeling the vehicle as the sum of its parts, and expose these parts using methods. It is essentially the same as the version with public fields and a plain old C struct -- hence a data structure. Hiding data and exposing methods is not enough to create an object, you have to consider if the methods actually expose behavior or just the data!

When you mix the two approaches, e.g. exposing getEngine() along with startEngine(), you end up with a "hybrid". I don't have Martin's Book at hand, but I remember that he did not recommend hybrids at all, as you end up with the worst of both worlds: Objects where both data and behavior is hard to change.

Your questions concerning HashMaps and Strings are a bit tricky, as these are pretty low level and don't fit quite well in the kinds of classes you will be writing for your applications. Nevertheless, using the definitions given above, you should be able to answer them.

A HashMap is an object. It exposes its behavior to you and hides all the nasty hashing details. You tell it to put and get data, and don't care which hash function is used, how many "buckets" there are, and how collisions are handled. Actually, you are using HashMap solely through its Map interface, which is quite a good indication of abstraction and "real" objects.

Don't get confused that you can use instances of a Map as a replacement for a data structure!

// A data structurepublic class Point {    public int x;    public int y;}// A Map _instance_ used instead of a data structure!Map<String, Integer> data = new HashMap<>();data.put("x", 1);data.put("y", 2);

A String, on the other hand, is pretty much an array of characters, and does not try to hide this very much. I guess one could call it a data structure, but to be honest I am not sure if much is to be gained one way or the other.

This is what, I believe, Robert. C. Martin was trying to convey:

1. Data Structures are classes that simply act as containers of structured data. For example:

   public class Point {    public double x;    public double y;}

2. Objects, on the other hand, are used to create abstractions. An abstraction is understood as:

   a simplification of something much more complicated that is going on under the covers The Law of Leaky Abstractions, Joel on Software

   So, objects hide all their underpinnings and only let you manipulate the essence of their data in a simplified way. For instance:

   public interface Point {    double getX();    double getY();    void setCartesian(double x, double y);    double getR();    double getTheta();    void setPolar(double r, double theta);}

   Where we don't know how the Point is implemented, but we do know how to consume it.

As I see it , what Robert Martin tries to convey, is that objects should not expose their data via getters and setters unless their sole purpose is to act as simple data containers. Good examples of such containers might be java beans, entity objects (from object mapping of DB entities), etc.

The Java Collection Framework classes, however, are not a good example of what he's referring to, since they don't really expose their internal data (which is in a lot of cases basic arrays). It provides abstraction that lets you retrieve objects that they contain. Thus (in my POV) they fit in the "Objects" category.

The reasons are stated by the quotes you added from the book, but there are more good reasons for refraining from exposing the internals. Classes that provide getters and setters invite breaches of the Law of Demeter, for instance. On top of that, knowing the structure of the state of some class (knowing which getters/setters it has) reduces the ability to abstract the implementation of that class. There are many more reasons of that sort.