For example, Amazon's S3 web service has a concept of buckets which hold objects. But, there's no reason why these objects can't be referred to as files since that's all they really are. Files are a collection of data on a file system. Data can be structured to represent many different things such as records in a database, images on a hard drive, or music on an MP3 player.
What makes an object special is that it is not only data, but has behavior, too. In order to see or act on the data inside an object, it must be accessed through its methods. Generally speaking, this is the only (and preferred) way of reading, writing, and updating an object's data.
This may not seem like a big deal, but it is since, whenever an object is passed around, all of its behavior is passed along, too.
For example, in a non-object world, I could read data from a database, manipulate it, perhaps improperly like incorrectly calculating tax or interest, and then update the database with the bad data.
However, if I pass along an object representing that same data from the database, the methods (i.e. business logic) that wrap and act on that data, protect the data's integrity. How the data is manipulated can be private, like a black box, but how you can access it is publicly described by its application programming interface (API).
I don't need to know how my car engine works or how gasoline is made, all I need to do is plug the gas hose into my gas tank. If I try to stick the diesel hose into the my tank, it won't fit.
The beauty of objects is that they can be plugged into each other and the data just flows. This is very different from previous programming paradigms, such as procedural languages, like BASIC, where each step of the program must be followed in sequence; or declarative languages like SQL where the programmers don't describe the steps to take, rather they declare what is to be accomplished, such as, "show me all the people with the last name equal to Smith."
No comments:
Post a Comment