Instructor: So now, with all of that out of the way,
let's dive into the first important concept I wanna cover
in this section.
And that's the difference between real objects
and data structures.
Though I also wanna already make it clear that both terms,
real objects and data structures, are made up terms.
These are not official terms you will find anywhere,
but this is simply a differentiation
which you sometimes find out there,
which can make sense when you're working with objects.
So what is the difference between real objects
and data structures or data containers,
as we could also call it?
A real object hides its internals, its properties,
for example, by making them private,
and it just exposes a public API, a couple of methods,
which allow you to do various things with this object.
And with these methods,
I don't just mean getters and setters
for these hidden properties.
I mean real abstractions,
so methods which do more complex things
than just setting a property
and therefore, acting as a proxy.
Data containers or data structures,
on the other hand, are simple objects where the properties
and internals are made available publicly
and where we have almost no public API besides that,
almost no methods.
Therefore real objects matter a lot
if you're following an object-oriented programming style,
And even if you don't,
some real objects could be helpful for encapsulating
and grouping logic together
and today contain your core business logic, therefore.
On the other hand, data containers are really just that.
These are objects which are just used
to store and transport data.
For real objects, as I mentioned a couple of seconds ago,
we prefer abstractions over concretions,
which is a fancy term which simply means
that we wanna expose methods which define a certain task
that should be done, and then we don't care
about how the object executes this task.
Whereas, a data container doesn't really have any methods,
and therefore, there we just have the concrete data,
which is stored inside of it,
and we can utilize that data in the places
where we get access to the data container.
So we don't tell the container to do something
as we would to do it with a real object.
We just can use it however we need to use it.
And for example, here we have a database class
which could be used to create real objects
because it's hiding its internals
and it then has a public API
which abstracts away the internals.
Connect and disconnect are pretty high level methods,
which then internally do everything to set up a connection
or to close a connection.
And we don't know what exactly the class will do internally
if we just call these methods.
That is what abstraction means.
We just connect to a database, which is an abstract concept,
and how exactly that works is hidden away from us
and is not our business
if we are using such a database object.
On the other hand, this user credentials clause here
could be used to simply create
a user credentials data container.
All the data is exposed publicly.
We have no methods, and we could just use objects
based on this class to pass credentials around, for example,
for example, as a parameter to a function or a method.
And that's the difference between real objects
and data containers.
We can use classes for both to define these objects,
but then how we use them differs.
And now of course, the question
is why does this matter at all?
Why should you care?