See Clive's answer about how views module hooks into the blocks, pages, etc. I rather thought you are looking for "How come Views is object-oriented, and has classes, while other Drupal functionality is mostly procedural code.
The best way to start the answer is probably by explaining a View instance.
See that, each "View" is actually an instance of view class. This class is the base class of all views. Modules do not extend or implement this base view class.
Furthermore, Views module, at least until Drupal 7.x-3.x, do not use all object-oriented functionality. You will not see interfaces or abstract classes to enforce specific methods or properties, but the convention is extend a parent class. You could create a completely new handler or plugin without extending or implementing any other class.
You will note name, description, tag, base_table, etc are basic properties of the View. These values are directly stored in the views_view table.
Then, each View can have one or more displays. Now that we are talking about displays keep in mind that every block, page, attachment, RSS feed, slideshow, map, etc is technically a plugin of type display.
Views module comes with basic displays, such as block, page, that Views module provide classes for. Modules can introduce new plugins by implementing hook_views_plugins.
There are other types of plugins, such as pager plugin, style, query, etc. In the Views module folder, take a look at the available plugins in ./plugins folder.
These plugins simply introduce new functionality: for example, create a slideshow from handlers, show rows in a map, create block content and a subject, check access, etc. When a module is introducing a new query, chances are most of the core logic already exists in the default query plugin class. Modules can simply extend this existing class and make adjustments in the new class of its own.
These plugins are not responsible about the actual data. This is where handlers come into play. A handler is basically, a set of instructions on how to handle a field, filter, argument or a sort criteria".
Handlers are responsible about actual data and instructions on how to handle data. Each and every field, filter, argument or sort criteria known to Views has a handler class. Views module comes with simple handlers for each of these handler types.
These basic handlers include handling a field as a number, using an IN query for node table's type field, a node ID argument, sorting rows by the node created date, etc.
Node ID and created date both fields are integers in the database. But, in the Views UI, you can configure which date format you want to display the created date in, but you can't do it for the node ID. Notice the difference here. Node ID column is handled by some class, and it is not the exact same as the handler responsible for node created field. However, you will notice some similarities in both fields.
See views module folder's handlers folder for views-provided handlers. Again, modules do not need to introduce new handlers to the View, but they must be available in the run time (this is taken care by Drupal class autoloading with .info file).
In hook_views_data, you can define which filters must be used to handle a particular table column. Views will then call query(), render() and other methods of the specified handler class and perform that action. If your table column's data type can be handled with an existing class, you simply define that existing class. Otherwise, you can create new handle, ideally extending an existing one that is the closest to what you need, and make adjustments to it. I used "ideally" here, because it's not necessary to make the classes an implementation of another class, but they must have methods to satisfy the plugins used in the View.
