> In my view, literately programmed code > should be visible for every programmer > through its evolution, so literate > programming doesn't cope with OCP well. > I guess it is why he prefer "re-editable" > code to reusable black box code. > But I think benefits of information > hiding should not be sacrificed.
I prefer to take a more formal view. There are four levels of specification: defined, implementation defined, unspecified and undefined.
You should be able to re-edit implementation defined facts. The problem is the model you choose to write your programs in gets translated into an application binary interface that necessitates encapsulation. However, as Robert Young could probably point out, encapsulation is not nearly an important principle as data independence. In fact, the ability to break encapsulation while mathematically preserving functionality leads to optimizations! Sometimes the abstractions preserved by encapsulation are fundamentally too coarse-grained to be re-usable and shareable in complex systems. Moreover, in many systems today, encapsulation is ill-defined and results in ambiguous copy and transfer semantics: In C++, the compiler needs to know if an object embedded inside another object is owned by the object instance conceptually or merely related to the object instance. However, the proposed constraint solver for C++0x will fix this somewhat. Furthermore, many systems do not define guarantees between the caller and the callee, such as exception safety, so valuing their encapsulation is dubious at best if you don't know what the input and output wires map to.
Finally, anything unspecified complicates understanding of a system. Some systems have formal semantics that are complete, and so it is impossible for the system's configuration space to contain an unknown configuration.
Flat View: This topic has 38 replies
on 39 pages
[
«
|
36373839
]
Previous Topic
