📄 appendc.htm
字号:
repeat yourself</B>. If a piece of code is recurring in many methods in derived
classes, put that code into a single method in the base class and call it from
the derived-class methods. Not only do you save code space, you provide for easy
propagation of changes. Sometimes the discovery of this common code will add
valuable functionality to your interface.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I13'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I14>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Watch
for <I>switch</I> statements or chained <I>if-else</I> clauses</B>. This is
typically an indicator of <I>type-check coding</I>, which means you are choosing
what code to execute based on some kind of type information (the exact type may
not be obvious at first). You can usually replace this kind of code with
inheritance and polymorphism; a polymorphic method call will perform the type
checking for you, and allow for more reliable and easier extensibility.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I14'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I15>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>From
a design standpoint, look for and separate things that change from things that
stay the same</B>. That is, search for the elements in a system that you might
want to change without forcing a redesign, then encapsulate those elements in
classes. You can learn significantly more about this concept in <I>Thinking in
Patterns with Java</I>, downloadable at <I>www.BruceEckel.com</I>.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I15'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I16>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Don’t
extend fundamental functionality by subclassing</B>. If an interface element is
essential to a class it should be in the base class, not added during
derivation. If you’re adding methods by inheriting, perhaps you should
rethink the design.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I16'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I17>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Less
is more</B>. Start with a minimal interface to a class, as small and simple as
you need to solve the problem at hand, but don’t try to anticipate all the
ways that your class <I>might</I> be used. As the class is used, you’ll
discover ways you must expand the interface. However, once a class is in use you
cannot shrink the interface without disturbing client code. If you need to add
more methods, that’s fine; it won’t disturb code, other than forcing
recompiles. But even if new methods replace the functionality of old ones, leave
the existing interface alone (you can combine the functionality in the
underlying implementation if you want). If you need to expand the interface of
an existing method by adding more arguments, create an overloaded method with
the new arguments; this way you won’t disturb any existing calls to the
existing method.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I17'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I18>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Read
your classes aloud to make sure they’re logical</B>. Refer to the
relationship between a base class and derived class as “is-a” and
member objects as “has-a.”
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I18'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I19>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>When
deciding between inheritance and composition, ask if you need to upcast to the
base type</B>. If not, prefer composition (member objects) to inheritance. This
can eliminate the perceived need for multiple base types. If you inherit, users
will think they are supposed to upcast.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I19'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I20>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Use
data members for variation in value and method overriding for variation in
behavior</B>. That is, if you find a class that uses state variables along with
methods that switch behavior based on those variables, you should probably
redesign it to express the differences in behavior within subclasses and
overridden methods.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I20'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I21>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Watch
for overloading</B>. A method should not conditionally execute code based on the
value of an argument. In this case, you should create two or more overloaded
methods instead.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I21'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I22>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Use
exception hierarchies</B>—preferably derived from specific appropriate
classes in the standard Java exception hierarchy. The person catching the
exceptions can then catch the specific types of exceptions, followed by the base
type. If you add new derived exceptions, existing client code will still catch
the exception through the base type.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I22'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I23>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Sometimes
simple aggregation does the job</B>. A “passenger comfort system” on
an airline consists of disconnected elements: seat, air conditioning, video,
etc., and yet you need to create many of these in a plane. Do you make private
members and build a whole new interface? No—in this case, the components
are also part of the public interface, so you should create public member
objects. Those objects have their own private implementations, which are still
safe. Be aware that simple aggregation is not a solution to be used often, but
it does happen.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I23'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I24>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Consider
the perspective of the client programmer and the person maintaining the
code</B>. Design your class to be as obvious as possible to use. Anticipate the
kind of changes that will be made, and design your class so that those changes
will be easy.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I24'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I25>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Watch
out for “giant object syndrome.”</B> This is often an affliction of
procedural programmers who are new to OOP and who end up writing a procedural
program and sticking it inside one or two giant objects. With the exception of
application frameworks, objects represent concepts in your application, not the
application.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I25'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I26>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>If
you must do something ugly, at least localize the ugliness inside a class</B>.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I26'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I27>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>If
you must do something nonportable, make an abstraction for that service and
localize it within a class</B>. This extra level of indirection prevents the
nonportability from being distributed throughout your program. (This idiom is
embodied in the <I>Bridge </I>Pattern).
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I27'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I28>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Objects
should not simply hold some data</B>. They should also have well-defined
behaviors. (Occasionally, “data objects” are appropriate, but only
when used expressly to package and transport a group of items when a generalized
container is innappropriate.)
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I28'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I29>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Choose
composition first when creating new classes from existing classes</B>. You
should only used inheritance if it is required by your design. If you use
inheritance where composition will work, your designs will become needlessly
complicated.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I29'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I30>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Use
inheritance and method overriding to express differences in behavior, and fields
to express variations in state</B>. An extreme example of what not to do is
inheriting different classes to represent colors instead of using a
“color” field.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I30'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I31>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Watch
out for <I>variance</I></B>. Two semantically different objects may have
identical actions, or responsibilities, and there is a natural temptation to try
to make one a subclass of the other just to benefit from inheritance. This is
called variance, but there’s no real justification to force a
superclass/subclass relationship where it doesn’t exist. A better solution
is to create a general base class that produces an interface for both as derived
classes—it requires a bit more space, but you still benefit from
inheritance, and will probably make an important discovery about the design.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I31'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I32>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Watch
out for <I>limitation</I> during inheritance</B>. The clearest designs add new
capabilities to inherited ones. A suspicious design removes old capabilities
during inheritance without adding new ones. But rules are made to be broken, and
if you are working from an old class library, it may be more efficient to
restrict an existing class in its subclass than it would be to restructure the
hierarchy so your new class fits in where it should, above the old class.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_APPENDIXC_I32'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_APPENDIXC_I33>
</FONT><LI><FONT FACE="Verdana"><B> </B></FONT><FONT FACE="Georgia"><B>Use
design patterns to eliminate “naked functionality.”</B> That is, if
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -