In theory but my experience has been that isolating everything creates as much work as it saves. There are cases where having a view can keep you from having to change blocks of code, and in those cases go ahead and make one. But in many cases the view just adds another step to the update of the table since you end up having to care the change through the view. Thus creating views of everything as a policy doesn't really help.
The underlying problem (and this applies to all encapsulation) is that any substantial change to the data type or organization problems means there are flaws with the buisness or presentation logic that need corrected also.* If I discover that that table needs to be broken into two because part of it is actually a many to one relation to the other part, creating a view to hide the table split doesn't get me anything most of the time. That is because the fundamental change probably broke the buisness and screen logic tied to that table.
Using views for SQL tables will depend a bit on what languages you are using though. My experience is mostly with VB, along with a smattering of C and other languages. In a weakly types, objected oriented system you can probably gain more benefit from encapsulation because you are playing into the languages strengths.
Jay
* This should not be taken as saying it's a bad idea. Only that it isn't the panacea that some people make it out to be.