Microsoft/alguidelines
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Handled replaced by IsHandled

Browse source
This commit is contained in:
Thomas Williamson 2021-12-03 16:06:27 +01:00
parent 10a2d6899e
commit adb65ef1ac
1 changed files with 17 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

34
content/BCPatterns/generic-method-pattern/index.md
View file

@ -49,18 +49,18 @@ codeunit 53100 "WLD BlockCustomer Meth"
{ {
internal procedure BlockCustomer(var Cust: Record Customer; HideDialog: Boolean) internal procedure BlockCustomer(var Cust: Record Customer; HideDialog: Boolean)
var var
Handled: Boolean; IsHandled: Boolean;
begin begin
if not ConfirmBlockCustomer(HideDialog) then exit; if not ConfirmBlockCustomer(HideDialog) then exit;
OnBeforeBlockCustomer(Cust, Handled); OnBeforeBlockCustomer(Cust, IsHandled);
DoBlockCustomer(Cust, Handled); DoBlockCustomer(Cust, IsHandled);
OnAfterBlockCustomer(Cust); OnAfterBlockCustomer(Cust);
AcknowledgeBlockCustomer(HideDialog) AcknowledgeBlockCustomer(HideDialog)
end; end;
local procedure DoBlockCustomer(var Cust: Record Customer; Handled: Boolean); local procedure DoBlockCustomer(var Cust: Record Customer; IsHandled: Boolean);
begin begin
if Handled then if IsHandled then
exit; exit;
Cust.Blocked := Cust.Blocked::All; Cust.Blocked := Cust.Blocked::All;
@ -88,7 +88,7 @@ codeunit 53100 "WLD BlockCustomer Meth"
end; end;
[IntegrationEvent(false, false)] [IntegrationEvent(false, false)]
local procedure OnBeforeBlockCustomer(var Cust: Record Customer; var Handled: Boolean); local procedure OnBeforeBlockCustomer(var Cust: Record Customer; var IsHandled: Boolean);
begin begin
end; end;
@ -120,7 +120,7 @@ codeunit 53100 "WLD BlockCustomer Meth"
{ {
internal procedure BlockCustomer(var Cust: Record Customer; HideDialog: Boolean) internal procedure BlockCustomer(var Cust: Record Customer; HideDialog: Boolean)
var var
Handled: Boolean; IsHandled: Boolean;
begin begin
if not ConfirmBlockCustomer(HideDialog) then exit; if not ConfirmBlockCustomer(HideDialog) then exit;
... ...
@ -161,17 +161,17 @@ codeunit 53100 "WLD BlockCustomer Meth"
{ {
internal procedure BlockCustomer(var Cust: Record Customer; HideDialog: Boolean) internal procedure BlockCustomer(var Cust: Record Customer; HideDialog: Boolean)
var var
Handled: Boolean; IsHandled: Boolean;
begin begin
... ...
OnBeforeBlockCustomer(Cust, Handled); OnBeforeBlockCustomer(Cust, IsHandled);
... ...
OnAfterBlockCustomer(Cust); OnAfterBlockCustomer(Cust);
... ...
end; end;
... ...
[IntegrationEvent(false, false)] [IntegrationEvent(false, false)]
local procedure OnBeforeBlockCustomer(var Cust: Record Customer; var Handled: Boolean); local procedure OnBeforeBlockCustomer(var Cust: Record Customer; var IsHandled: Boolean);
begin begin
end; end;
@ -192,16 +192,16 @@ codeunit 53100 "WLD BlockCustomer Meth"
{ {
internal procedure BlockCustomer(var Cust: Record Customer; HideDialog: Boolean); internal procedure BlockCustomer(var Cust: Record Customer; HideDialog: Boolean);
var var
Handled: Boolean; IsHandled: Boolean;
begin begin
... ...
DoBlockCustomer(Cust, Handled); DoBlockCustomer(Cust, IsHandled);
... ...
end; end;
local procedure DoBlockCustomer(var Cust: Record Customer; Handled: Boolean); local procedure DoBlockCustomer(var Cust: Record Customer; IsHandled: Boolean);
begin begin
if Handled then if IsHandled then
exit; exit;
Cust.Blocked := Cust.Blocked::All; Cust.Blocked := Cust.Blocked::All;
@ -266,9 +266,9 @@ As I said, it will facilitate a lot of advantages. Let's explain a bit more in
Thanks to the *event layer*, by applying this pattern for all methods, we will automatically have the bare minimum of events that we need to hook into a method: the `OnBefore-` and the `OnAfter`. Of course it would make sense to even add more events to the method when appropriate (eg, when you're inserting a record in a table, it might be interesting to also raise an event just before you call the insert). Thanks to the *event layer*, by applying this pattern for all methods, we will automatically have the bare minimum of events that we need to hook into a method: the `OnBefore-` and the `OnAfter`. Of course it would make sense to even add more events to the method when appropriate (eg, when you're inserting a record in a table, it might be interesting to also raise an event just before you call the insert).
### Decoupling ### Decoupling
Thanks to these same events, and the fact the pattern foresees a handler as well, we are able to "decouple" our method as well. What do I mean with that? Well, we can simply subscribe to the `OnBefore`event, and set `Handled` to `true`. This means it will never execute the do-procedure, which means, the original procedure/method/business logic is "decoupled". Thanks to these same events, and the fact the pattern foresees a handler as well, we are able to "decouple" our method as well. What do I mean with that? Well, we can simply subscribe to the `OnBefore`event, and set `IsHandled` to `true`. This means it will never execute the do-procedure, which means, the original procedure/method/business logic is "decoupled".
We can use this obviously for implementing our own method (a new way to accomplish this method), or to disable the method by simply subscribing to it, and only providing the `Handled := true` in our subscriber. However, there are many more usages where we can use this for. We can use this obviously for implementing our own method (a new way to accomplish this method), or to disable the method by simply subscribing to it, and only providing the `IsHandled := true` in our subscriber. However, there are many more usages where we can use this for.
Maybe one more example: Maybe one more example:
if you would apply this pattern to your product, at the customer, you'll be able to hotfix your methods simply by decoupling them and fixing the method instead of waiting for a hotfix from the hotfix-departement. if you would apply this pattern to your product, at the customer, you'll be able to hotfix your methods simply by decoupling them and fixing the method instead of waiting for a hotfix from the hotfix-departement.
@ -300,7 +300,7 @@ The pattern describes the tests that needs to be written.
*Disabling methods* *Disabling methods*
Coming back to the "decoupling" part - in tests, you actually might need it more than you realize. Just imagine: you want to test method 1, but method 2 comes in the way by interfering with configurations that you need to do, or UI that is popping up, while it could be completely pointless. Coming back to the "decoupling" part - in tests, you actually might need it more than you realize. Just imagine: you want to test method 1, but method 2 comes in the way by interfering with configurations that you need to do, or UI that is popping up, while it could be completely pointless.
Solution: simply - within your test-codeunit - subscribe (with a manual subscriber) to method 2, set `Handled` to `false` - done! Solution: simply - within your test-codeunit - subscribe (with a manual subscriber) to method 2, set `IsHandled` to `false` - done!
### Encapsulation ### Encapsulation
Don't underestimate the power of the encapsulation part of this pattern. One of the first questions that people ask themselves when reading into this pattern is: "*isn't it going to consume all my codeunit-id's*" or "*so many codeunits, that can't be readable, right?*". Don't underestimate the power of the encapsulation part of this pattern. One of the first questions that people ask themselves when reading into this pattern is: "*isn't it going to consume all my codeunit-id's*" or "*so many codeunits, that can't be readable, right?*".