深層複製合成物件時，必須假設成員物件的 clone() 也能正確深層複製其參考，以此類推。這要求對所有涉及類別的代碼有控制權，或至少完整掌握其深層複製正確性。

回顧前文 Vector 範例，此次 Int2 實作 Cloneable，可對 Vector 進行真正深層複製： //: AddingClone.java im

對象序列化後再反序列化，實質經歷一個「複製」過程。為何不直接用序列化做深層複製？以下程式碼對比兩種方法效能： //: Compete.java import

新建類別預設繼承 Object 且無複製能力。可在任一繼承層級加入複製能力，之後所有子類自動擁有： //: HorrorFlick.java import j

clone 設計之所以怪異，確有歷史原因。未經證實的內幕故事如下： 初衷：硬體控制語言 Java 最初設計為控制硬體的語言，與網際網路無關。作為大眾化語言，理念

單純將 clone() 設為 private 無法禁用複製（衍生類無法縮小存取範圍）。針對類別的複製能力，有六種控制策略： 保持中立：不處理複製。衍生類自行決

複製建構子是 C++ 基礎機制，可自動產生本地副本。但在 Java 並不適用。以下範例展示完整複製建構子實作與其失效場景： //: CopyConstruct

clone() 雖能產生本地副本，但程式設計師必須自行防範別名副作用。若提供通用庫無法保證正確克隆，或想保留別名優勢（避免不必要複製）卻避免副作用，該如何處理？

完全可自行建立唯讀類別。下例示範 Immutable1： //: Immutable1.java public class Immutable1 {

不可變類別看似優雅，但頻繁修改時需不斷建立新物件，導致大量 GC 壓力。對 String 等類別代價過高。 解決方案：可變夥伴類 建立可變夥伴類（Mutable

觀察下列代碼： //: Stringer.java public class Stringer { static String upcase(Stri

整理 String 與 StringBuffer 共通與各自關鍵方法，掌握兩者溝通方式。表格僅含討論相關核心方法，被覆寫方法以單行摘要。 String 類別核心

Java 所有物件皆在堆積區建立，透過參考（handle）操作，垃圾收集器自動管理記憶體。這簡化了物件傳遞與返回，但帶來兩大代價： 額外記憶體管理效率損耗（雖

Java 1.0 AWT 目標是跨平台統一 GUI，但事與願違：各平台顯示效果同樣欠佳，僅支援四種字體，無法存取 OS 高階 GUI 元件，程式模型非物件導向且

這是給初學者的手機遊戲開發心得，涵蓋開發環境選擇、平台比較與 J2ME 實戰配置。 是否必須購買真機？ 初學階段不必買真機，先在模擬器練習。但若要產品化，建議配

舊版 AWT 在物件導向設計與 GUI 開發套件設計上表現不盡如人意，被評為「拙劣、可怕、惡劣」。它將程式設計拉回黑暗年代：每個事件都需手寫代碼，連其他環境用「

程式庫通常依功能組織。Java 標準庫中的 String 和 Vector 即屬此類。另一些庫專為建構其他庫而設計，提供應用程式框架——透過繼承框架類別並覆寫特

無需建立網路連線即可進行簡易測試：啟動瀏覽器開啟包含 <applet> 標籤的 HTML 檔案即可。Sun JDK 內建的「Applet Viewe

上個範例較為單調，現在加入一些有趣的圖形元素。以下程式碼示範如何繪製字串並以 3D 矩形框住它： //: Applet2.java // Easy graph

觀察 Applet 框架方法的實際運作相當有趣。本例重點展示 init()、start() 和 stop() 三個核心方法，因為 paint() 和 destr