您也可以使用Role Object模式和良好的老聚集。
不是讓智能實體包含所有業務邏輯,而是讓他們變傻,然後將所有業務邏輯轉移到聚集啞實體的角色中。你的行爲是那些生活在角色中的一流公民。
實施例:
interface BannableUser
{
public function ban();
}
具有帶有一個特定行爲的接口如下所述接口分離原則。它還大大增加了可能的重用,因爲與具有特定於應用程序的行爲集合相比,您更可能重用單個行爲。
我們實現這一點,你創建一個合適的角色類:
class BannableUserRole implements BannableUser
{
private $user;
public function __construct(User $user)
{
$this->user = $user;
}
public function ban()
{
$this->user->isBanned = true;
}
}
你仍然有一個用戶實體,但它完全剝離所有的行爲。它本質上只是一袋吸氣劑和固體劑或公共財產。它代表你的系統是。這是數據部分,而不是交互部分。互動現在在角色裏面。
class User
{
public $isBanned;
// … more properties
}
現在,假設你有某種形式的Web UI,你可以做你的控制器中的以下內容:
class BanUserController implements RequestHandler
{
// …
public function handleRequest(Request $request)
{
$userId = $request->getVar('user_id');
$user = $this->userRepository->findById($userId);
$bannableUser = new BannableUserRole($user);
$bannableUser->ban();
}
}
您可以通過移動的用戶和分配的實際查找進一步分離這角色到一個UseCase類。讓我們把它叫做語境:
class BanUserContext implements Context
{
public function run($userId)
{
$user = $this->userRepository->findById($userId);
$bannableUser = new BannableUserRole($user);
$bannableUser->ban();
}
}
現在你把所有的業務邏輯模型層內,從您的用戶界面完全隔離。上下文是你的系統確實。您的控制器將僅授權給適當的上下文:
class BanUserController implements RequestHandler
{
// …
public function handleRequest(Request $request)
{
$this->banUserContext->run($request->getVar('user_id'));
}
}
就是這樣。無需Runkit或類似的駭客。以上是數據上下文交互體系結構模式的簡化版本,以備您進一步研究。
你是什麼特別的要求,往往如果你解釋你的問題的人可以提出替代解決方案 –
壞主意,代碼生成在運行期間。 – JvdBerg
您是否在尋找[Lazy Loading](http://martinfowler.com/eaaCatalog/lazyLoad.html)?請添加更多的上下文,因爲有幾種方法可以通過常規的設計模式來實現,但哪一種方法取決於爲什麼以及爲什麼需要這樣做。 – Gordon