<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Java設計原則 on [Lou's lab]</title><link>/tags/java%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87/</link><description>Recent content in Java設計原則 on [Lou's lab]</description><generator>Hugo -- gohugo.io</generator><language>zh-tw</language><copyright>Copyright ©2020 Lou</copyright><lastBuildDate>Sun, 22 Jun 2025 22:30:00 +0800</lastBuildDate><atom:link href="/tags/java%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87/index.xml" rel="self" type="application/rss+xml"/><item><title>Effective Java Item25：將原始碼檔案限制為單一top-level的類別</title><link>/posts/book/effective-java-item25/</link><pubDate>Sun, 22 Jun 2025 22:30:00 +0800</pubDate><guid>/posts/book/effective-java-item25/</guid><description>&lt;p>整理 &lt;strong>Effective Java&lt;/strong> 書中 Item 25：Limit source files to a single top-level class 心得筆記&lt;/p>
&lt;h2 id="主旨保持一檔一類別避免隱藏的地雷">主旨：保持一檔一類別，避免隱藏的地雷&lt;/h2>
&lt;p>Java 技術上允許你在一個 &lt;code>.java&lt;/code> 檔案中定義多個 top-level 類別（也就是非巢狀的 public 或 package-private 類別），但這麼做其實是一個&lt;strong>踩雷設計&lt;/strong>。這會讓你的程式行為變得難以預測，尤其當你在不同檔案中定義了相同名稱的類別，編譯結果會依照檔案的編譯順序而不同，產生極大的風險。&lt;/p></description></item><item><title>Effective Java Item24：比起非靜態成員類型，更偏好靜態成員類型</title><link>/posts/book/effective-java-item24/</link><pubDate>Sat, 21 Jun 2025 22:30:00 +0800</pubDate><guid>/posts/book/effective-java-item24/</guid><description>&lt;p>整理 &lt;strong>Effective Java&lt;/strong> 書中 Item 24: Prefer static member classes to non-static member classes 心得筆記&lt;/p>
&lt;h2 id="主旨">主旨&lt;/h2>
&lt;p>在 Java 中，巢狀類別（Nested Class）是一種將類別定義在另一個類別內部的設計方式。根據是否需要外部類別的實例，有四種巢狀類別：&lt;code>static member class&lt;/code>、&lt;code>non-static member class&lt;/code>、&lt;code>local class&lt;/code> 和 &lt;code>anonymous class&lt;/code>。本篇聚焦在：&lt;strong>當巢狀類別不需要外部類別實例時，應優先使用 static member class&lt;/strong>，這樣可以節省記憶體、提升效能、避免記憶體洩漏，也對設計更有彈性。&lt;/p></description></item><item><title>Effective Java Item22：介面只能拿來定義型別，不要拿來存常數</title><link>/posts/book/effective-java-item22/</link><pubDate>Thu, 19 Jun 2025 22:30:00 +0800</pubDate><guid>/posts/book/effective-java-item22/</guid><description>&lt;p>整理 &lt;strong>Effective Java&lt;/strong> 書中 Item 22: Prefer interfaces to abstract classes 心得筆記&lt;/p>
&lt;h2 id="主旨">主旨&lt;/h2>
&lt;p>Java 的介面（interface）本質是用來定義「型別」的 —— 換句話說，介面要描述的是「這個物件可以做什麼」。如果你只是想要存一些常數，卻用介面來達成，那麼你就誤用了這個語言工具。&lt;/p></description></item><item><title>Effective Java Item20：盡量使用介面，而非抽象類別</title><link>/posts/book/effective-java-item20/</link><pubDate>Tue, 17 Jun 2025 22:30:00 +0800</pubDate><guid>/posts/book/effective-java-item20/</guid><description>&lt;p>整理 &lt;strong>Effective Java&lt;/strong> 書中 Item 20: Prefer interfaces to abstract classes 心得筆記&lt;/p>
&lt;h2 id="主旨">主旨&lt;/h2>
&lt;p>Java 提供兩種方式定義「可以有多個實作」的類型：介面（interface）和抽象類別（abstract class）。在 Java 8 引入 default methods 之後，兩者都能提供方法實作。但總體來說，&lt;strong>介面更靈活、延伸性更好，也比較不會限制使用者的設計&lt;/strong>。本章重點就是告訴你：&lt;strong>大多數情況下，請選擇介面。&lt;/strong>&lt;/p></description></item><item><title>Effective Java Item19：設計可繼承的類別，否則就禁止繼承</title><link>/posts/book/effective-java-item19/</link><pubDate>Mon, 16 Jun 2025 22:00:00 +0800</pubDate><guid>/posts/book/effective-java-item19/</guid><description>&lt;p>整理 &lt;strong>Effective Java&lt;/strong> 書中 Item 19: Design and document for inheritance or else prohibit it 心得筆記&lt;/p>
&lt;h2 id="主旨">主旨&lt;/h2>
&lt;p>Java 裡的繼承功能很強，但使用起來也很危險。如果你打算讓別人「繼承你的類別」，你不只是要寫出可以用的 API，還要&lt;strong>公開類別的內部行為細節&lt;/strong>。如果沒做到這一點，繼承後的子類可能會在某次更新中爆掉。&lt;/p>
&lt;p>所以這一條的建議是：&lt;/p>
&lt;blockquote>
&lt;p>如果你沒打算讓別人繼承，就該禁止繼承；&lt;br>
如果你開放繼承，就要設計與文件都做到位。&lt;/p>
&lt;/blockquote></description></item><item><title>Effective Java Item18：用組合取代繼承</title><link>/posts/book/effective-java-item18/</link><pubDate>Sun, 15 Jun 2025 21:30:00 +0800</pubDate><guid>/posts/book/effective-java-item18/</guid><description>&lt;p>整理 &lt;strong>Effective Java&lt;/strong> 書中 Item 18: Favor composition over inheritance 心得筆記&lt;/p>
&lt;h2 id="主旨">主旨&lt;/h2>
&lt;p>繼承常被拿來重用程式碼，但其實風險也很高，尤其當你繼承的類別不是為了擴充而設計。這篇重點是：「&lt;strong>與其繼承一個現成的類別，不如把它包進一個欄位（組合）來用&lt;/strong>」，這樣可以避開繼承帶來的封裝破壞與潛在 bug，讓設計更穩健。&lt;/p></description></item></channel></rss>