Should all structures be ADTs?

Question

Is there any specific category an ADT must be in? I'm struggling to find out how best to represent objects in the program for example:

As a record:

struct Person {
    int age
};

Or as an ADT:

struct Person { int age; };

typedef struct Person* Person;

void Person_SetAge(Person person, int age);

Both represent the same thing, is it always preferrable to choose an ADT because it provides more features?

Answer 1

Data-Structure versus Object

I think the question you are asking is: Should I provide a data-structure and expect all of its users to follow the rules on updating the data-structure, or should I provide a set of interactions which observe all of the rules on updating a data-structure and hide the data-structure itself?

Congratulations; you have just discovered Encapsulation.

Style matters aside, struct, class, records are all forms of map. As in the days of yore, an exposed map tends to accumulate all manner of scribbles and annotations which can make it difficult if not impossible to use the map itself, or alternately can greatly enhance the map. It requires that everyone working on that map share the same understanding on how to read, use, and manipulate a map. It only requires one individual to do something unexpected by the others to make it unusable.

This is why encapsulation is important. The idea is to vet a small select group of users who have all of the knowledge about how to read, use, and manipulate the map who (because they are vetted) all have the same understanding and expectations about how to read, use, and manipulate the map. They in turn expose a much simpler understanding/enforce consistent usage. In code these would be the public functions that operate on the (map) struct.

Even better encapsulation leads us toward interfaces and protocols. Interfaces allow the indirect users to forget completely about there being a data-structure at all, and focus only on the actions that can be performed, and the order they can be performed (the protocol). Allowing a complete swap of physical implementation without disrupting any indirect user. Unfortunately this comes at the cost of specialised/optimised access, and to depending on how general the interface is a loss in expressiveness.

So the question really isn't should I use X or Y. It's who should have direct access, and who should have indirect access via a vetted manipulation. In some cases it's better to have direct access, but in other cases it's better to have indirect access.