Problems:
1.Why it is better to hide implementation details than expose them.
1.1 Changes don't affect the whols program.
1.2 It is easier to improve performance.
1.3 It will be easier to check codes and more confident to bilieve it is right.
1.4 The program becomse more self-documenting.
1.5 You don't have to pass data all over the program.
2.Do simple items need to be treated as ADTs?
Yes. You don't have to have a formidable data type to justify using an abstract data type. For example, a Light class which only has routines TurnOn and TurnOff is also a good ADT. You might think that it would be a waste to isolate simple "on" and "off" operations in routines of their own, but even simple operations can benefit from the use of ADTs. Putting the light and its operations into an ADT makes the code more self-documenting and easier to change, confines the potential consequences of changes to the TurnLightOn() and TurnLight-Off() routines, and reduces the number of data items you have to pass around.
3.How can object oriented technology be used in a non-object-oriented environment?
3.1 Pass ID to each routine.
3.2 Explicitly provide the data used by the ADT services. In this approach, you declare the data that the ADT uses within each routine that uses an ADT service.
3.3 Use implicit instances (with great care) by something like SetCurrentXX(XXID).
4.Should a inhertion expose redunda functions?
No. It fails the main test for inheritance, which is, "Is inheritance used only for "is a" relationships?"
5.What tips make a good encapsulation?
5.1 Minimize accessibility of classes and members
5.2 Don't expose member data in public
5.3 Avoid putting private implementation details into a class's interface
5.4 Don't make assumptions about the class's users
5.5 Avoid friend classes
5.6 Don't put a routine into the public interface just because it uses only public routines
5.7 Favor read-time convenience to write-time convenience
5.8 Be very, very wary of semantic violations of encapsulation