อ็อบเจ็กต์ถ่อมตนและขอบเขตมุมมอง
ประยุกต์ใช้รูปแบบอ็อบเจ็กต์ถ่อมตนเพื่อให้โค้ดมุมมองมีขนาดเล็กและทดสอบได้ โดยย้ายการตัดสินใจทั้งหมดไปยังตัวนำเสนอที่ทดสอบได้ตรงขอบเขตการนำเสนอ
อ็อบเจ็กต์ถ่อมตนและขอบเขตมุมมอง เป็นบทเรียน Clean Architecture & Design Patterns in Practice ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Clean Architecture & Design Patterns in Practice และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน
บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ
The Hardest Code to Test
UI code is notoriously hard to test: it touches frameworks, screens, and event loops.
The Humble Object pattern solves this by splitting behavior so that the hard-to-test part becomes humble — nearly logic-free.
The Pattern in One Idea
Separate code into two parts across a boundary:
- A humble part: thin, dumb, hard to test (the view).
- A testable part: holds all the logic (the presenter).
Almost all behavior moves to the testable side.
Applying It to the View
The view becomes humble: it only displays already-formatted data and forwards user events.
It contains no formatting decisions, no conditionals about what to show — just assignment of fields to widgets.
The View Interface
Define what the presenter can ask the view to display.
interface OrderView {
void showTotal(String formattedTotal);
void showError(String message);
}The Testable Presenter
The presenter does all the work and pushes finished strings to the humble view.
class OrderPresenter {
private final OrderView view;
OrderPresenter(OrderView view) { this.view = view; }
void present(double total) {
if (total < 0) { view.showError("Invalid total"); return; }
view.showTotal("$" + String.format("%.2f", total));
}
}Why This Is Testable
Because the presenter talks to a view interface, a test supplies a fake view and asserts what was shown — no framework required.
class FakeView implements OrderView {
String shown;
public void showTotal(String t) { shown = t; }
public void showError(String m) { shown = m; }
}A Runnable Example
The presenter formats; the humble view simply records what it was told.
public class Main {
interface View { void show(String s); }
static class Presenter {
final View v;
Presenter(View v){ this.v=v; }
void present(double total){ v.show(total<0 ? "Invalid" : "$"+String.format("%.2f", total)); }
}
static class FakeView implements View { String last; public void show(String s){ last=s; } }
public static void main(String[] a){
FakeView fv = new FakeView();
new Presenter(fv).present(12.5);
System.out.println("View shows: " + fv.last);
}
}The Boundary Is the Key
The humble object pattern always centers on a boundary interface. Logic lives on the testable side of that boundary; the framework lives on the humble side.
This is exactly how Clean Architecture keeps frameworks at arm length.
Where Else It Applies
- Database access: a humble gateway, testable logic above it.
- Hardware or sensors: humble drivers, testable controllers.
- Web handlers: humble controllers delegating to interactors.
Anywhere the framework boundary is hard to test.
Keeping the View Truly Humble
Resist sneaking logic back into the view. The moment a view starts deciding what to format or whether to show something, it stops being humble and becomes untestable again.
Guidelines
- Define a view interface the presenter drives.
- Put all formatting and branching in the presenter.
- Let the view only assign values and emit events.
- Test the presenter with a fake view.
Quick Check
Test your understanding of the Humble Object pattern.
Recap
You learned the Humble Object pattern for the view boundary.
- Split into a humble view and a testable presenter.
- All logic lives on the testable side of a boundary interface.
- This keeps frameworks out of your tests and your core.
เรียนรู้ Clean Architecture & Design Patterns in Practice ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 12
- บทเรียน
- 48
คำถามที่พบบ่อย
บทเรียน “อ็อบเจ็กต์ถ่อมตนและขอบเขตมุมมอง” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “อ็อบเจ็กต์ถ่อมตนและขอบเขตมุมมอง” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Clean Architecture & Design Patterns in Practice ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “อ็อบเจ็กต์ถ่อมตนและขอบเขตมุมมอง”
ประยุกต์ใช้รูปแบบอ็อบเจ็กต์ถ่อมตนเพื่อให้โค้ดมุมมองมีขนาดเล็กและทดสอบได้ โดยย้ายการตัดสินใจทั้งหมดไปยังตัวนำเสนอที่ทดสอบได้ตรงขอบเขตการนำเสนอ คุณปฏิบัติ Clean Architecture & Design Patterns in Practice ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Clean Architecture & Design Patterns in Practice หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Clean Architecture & Design Patterns in Practice บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “อ็อบเจ็กต์ถ่อมตนและขอบเขตมุมมอง” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Clean Architecture & Design Patterns in Practice นี้ได้ไหม
ได้ บทเรียน Clean Architecture & Design Patterns in Practice ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- ตัวนำเสนอและโมเดลมุมมอง
- การปรับใช้กับเว็บเฟรมเวิร์ก
- การทดสอบเลเยอร์การนำเสนอ
- อ็อบเจ็กต์ถ่อมตนและขอบเขตมุมมอง