0Pricing
Clean Architecture & Design Patterns in Practice · درس

الكائنات المتواضعة وحدّ العرض

طبّق نمط الكائن المتواضع للإبقاء على شيفرة العرض بسيطة وقابلة للاختبار، وانقل جميع القرارات إلى مقدّمات قابلة للاختبار عند حدّ طبقة العرض.

الكائنات المتواضعة وحدّ العرض درس مجاني في Clean Architecture & Design Patterns in Practice على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 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.

الأسئلة الشائعة

هل درس «الكائنات المتواضعة وحدّ العرض» مجاني؟

نعم — نص درس «الكائنات المتواضعة وحدّ العرض» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Clean Architecture & Design Patterns in Practice، انتقل إلى CoddyKit PRO. تتضمن دورة Clean Architecture & Design Patterns in Practice 4 دروس في المجموع.

ماذا ستتعلم في «الكائنات المتواضعة وحدّ العرض»؟

طبّق نمط الكائن المتواضع للإبقاء على شيفرة العرض بسيطة وقابلة للاختبار، وانقل جميع القرارات إلى مقدّمات قابلة للاختبار عند حدّ طبقة العرض. تتمرن على Clean Architecture & Design Patterns in Practice مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 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 يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

  1. Presenters وView Models
  2. التكيّف مع أُطر الويب
  3. اختبار طبقة العرض
  4. الكائنات المتواضعة وحدّ العرض
← العودة إلى Clean Architecture & Design Patterns in Practice