package dao;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import bean.User;
public class UserDao {
public boolean login(Connection connection,User user) throws SQLException
{
String sql="select * from user where ?=username and ?=password";
PreparedStatement preparedStatement=connection.prepareStatement(sql);
preparedStatement.setString(1, user.getUsername());
preparedStatement.setString(2, user.getPassword());
ResultSet resultSet=preparedStatement.executeQuery();
if(resultSet.next())
{
return true;
}
return false;
}
public int register(Connection connection,User user) throws SQLException
{
String sql="insert into user values(null,?,?)";
PreparedStatement preparedStatement=connection.prepareStatement(sql);
preparedStatement.setString(1, user.getUsername());
preparedStatement.setString(2, user.getPassword());
return preparedStatement.executeUpdate();
}
public int userupdate(Connection connection,User user) throws SQLException
{
String sql="update user set password=? where username=? ";
PreparedStatement preparedStatement=connection.prepareStatement(sql);
preparedStatement.setString(1, user.getPassword());
preparedStatement.setString(2, user.getUsername());
return preparedStatement.executeUpdate();
}
}
1．概要部分
（1）程式碼符合需求和規格說明麼？
根據程式碼所示，UserDao 類提供了 login、register 和 userupdate 三個方法，分別用於使用者登入、註冊和更新資訊。這些方法都使用了 PreparedStatement 類來執行 SQL 語句，並對引數進行了安全處理，因此可以認為程式碼符合需求和規格說明。
（2）程式碼設計是否考慮周全？
UserDao 類的方法都採用了物件導向的程式設計思想，將使用者登入、註冊和更新資訊的操作封裝成獨立的方法，提高了程式碼的可讀性和易用性。此外，UserDao 類使用了 PreparedStatement 類來執行 SQL 語句，提高了程式碼的安全性。
（3）程式碼可讀性如何？
UserDao 類的方法命名清晰，程式碼結構清晰，註釋完整，因此程式碼的可讀性較好。
（4）程式碼容易維護麼？
UserDao 類的方法都遵循了物件導向的程式設計原則，程式碼結構清晰，耦合度低，因此程式碼易於維護。
（5）程式碼的每一行都執行並檢查過了嗎？
該段程式碼只是定義了物件，連線資料庫，不存在邏輯錯誤
2．設計規範部分
（1）設計是否遵從已知的設計模式或專案中常用的模式？
UserDao 類使用了 PreparedStatement 類來執行 SQL 語句，這是一種常見的 JDBC 設計模式。此外，UserDao 類的方法都遵循了物件導向的程式設計原則，這也是一種常見的軟體設計模式。
（2）有沒有硬編碼或字串/數字等存在？
程式碼中沒有明顯的硬編碼字串或數字
（3）程式碼有沒有依賴於某一平臺，是否會影響將來的移植？
程式碼沒有明顯的平臺依賴性，因此不會影響將來的移植。
（4）開發者新寫的程式碼能否用已有的Library/SDK/Framework中的功能實現？在本專案中是否存在類似的功能可以呼叫而不用全部重新實現？
開發者可以使用資料庫來獲取結果而不需要重新實現這些功能
（5）有沒有無用的程式碼可以清除？
程式碼中沒有明顯的無用程式碼。
3．具體程式碼部分
（1)有沒有對錯誤進行處理?對於呼叫的外部函式，是否檢查了返回值或處理了異常？
程式碼中未明確體現對錯誤的處理機制。建議在關鍵部位新增異常捕獲和處理程式碼，例如：
在 login() 函式中，捕獲並處理資料庫查詢可能丟擲的異常。
在 register() 函式中，捕獲並處理資料庫插入可能丟擲的異常。
在 userupdate() 函式中，捕獲並處理資料庫更新可能丟擲的異常。
（2)引數傳遞有無錯誤，字串的長度是位元組的長度還是字元(可能是單/雙位元組)的長度 ，是以0開始計數還是以1 開始計數?
程式碼中未明確指定引數傳遞方式，也沒有對字串長度單位、索引起始位置進行定義。建議遵循以下約定：
明確指定引數傳遞方式（例如：值傳遞、引用傳遞）。
字串長度單位使用位元組或字元，並明確說明。
索引起始位置統一使用 0 或 1，並明確說明。
（3)邊界條件是如何處理的?switch語句的default分支是如何處理的?迴圈有沒有可能出現死迴圈 ?
程式碼中未明確體現邊界條件的處理邏輯。但是通常情況下，應該有相應的邏輯來處理可能的邊界情況，比如陣列越界、非法值等問題。
Switch語句的default分支通常會提供一個預設的行為，或者丟擲一個異常，表明不應該到達該分支。
當迴圈的條件沒有終止的時候，迴圈可能出現死迴圈。
（4)有沒有使用斷言(Assert)來保證我們認為不變的條件真的得到滿足?
程式碼中未使用斷言。斷言可以用來驗證程式中的一些基本假設，例如函式的輸入引數是否符合預期，資料結構的狀態是否正確等。
（5)對資源的利用，是在哪裡申請，在哪裡釋放的?有無可能存在資源洩漏(記憶體、檔案、各種GUI資源、資料庫訪問的連線，等等)?有沒有最佳化的空間?
程式碼中未明確體現資源的申請和釋放操作。通常情況下，資源應該在使用後立即釋放，以避免資源洩漏。對於記憶體、檔案、資料庫連線等資源，應該在不再需要時及時釋放。
（6)資料結構中有沒有用不到的元素?
程式碼中未發現明顯的資料結構最佳化空間。建議根據實際情況，考慮使用合適的資料結構提高效率，例如：
使用雜湊表代替線性表，提高查詢效率。
使用樹形結構代替線性結構，降低插入和刪除的複雜度。
4．效能
（1）程式碼的效能（Performance）如何？最壞的情況是怎樣的？
該程式碼的效能可能受到以下因素的影響：
資料庫查詢的效率。密碼加密解密的效率。資料傳輸的效率。在該程式碼中語句較少執行速度可觀
最壞的情況可能覆載過大導致系統執行緩慢或發生錯誤
（2）程式碼中，特別是迴圈中是否有明顯可最佳化的部分（C++中反覆建立類，C#中 string 的操作是否能用StringBuilder 來最佳化）？
該程式碼中未使用迴圈，無可最佳化的部分。如果在 C# 程式碼中頻繁操作字串，可以使用 StringBuilder 類來最佳化。StringBuilder 類可以高效地拼接字串，避免重複建立字串物件。
（3）對於系統和網路呼叫是否會超時？如何處理?
該程式碼不涉及網路呼叫，不存在超時問題。若發生超時可透過設定超時時間，使用非同步呼叫，使用重試機制等方法解決
5．程式碼可讀性如何？有沒有足夠的註釋？
UserDao 類的方法命名清晰，程式碼結構清晰，因此程式碼的可讀性較好。該程式碼僅定義物件，方法，連線資料庫故無註釋
6.可測試性
可測試性好的方面:
方法清晰簡單: UserDao 類中的每個方法都很簡單易懂，功能獨立，方便單獨測試。
使用 PreparedStatement: 使用 PreparedStatement 防止 SQL 注入漏洞，也方便測試時替換資料。
丟擲異常: 所有方法都丟擲 SQLException 異常，測試時可以方便的模擬資料庫異常情況。