Remove the Middleman object

concept: the "removal of the Middleman object" in this article refers to the removal of classes in the middle that do not play any other role, allowing the related two classes to interact directly.

text: Sometimes in our code there will be some "ghost class", design mode master Fowler called them "middleman" class, "Middleman" class in addition to invoke other objects do not do anything, so the "middleman" class does not exist, we can remove them from the code, This allows the two classes of the interaction to be directly correlated.

As the following code shows, theConsumer class wants to get accountdataprovider data, but the middle is involved in a Accountmanager class that doesn't have any role to associate, so we should remove it.

usingLosTechies.DaysOfRefactoring.PullUpField.After;namespacelostechies.daysofrefactoring.samplecode.removemiddleman.before{Public classConsumer{ PublicAccountmanagerAccountmanager {Get;Set; } PublicConsumer (AccountmanagerAccountmanager) {Accountmanager = Accountmanager; }Public voidGet (intID) {Account account = Accountmanager.getaccount (ID); }    }Public classAccountmanager{ PublicAccountdataproviderDataprovider {Get;Set; } PublicAccountmanager (AccountdataproviderDataprovider) {dataprovider = Dataprovider; } PublicAccount Getaccount (intID) {returnDataprovider.getaccount (ID); }    }Public classAccountdataprovider{ PublicAccount Getaccount (intID) {//Get Account}    }}

The refactored code is shown below,  and

usingLosTechies.DaysOfRefactoring.PullUpField.After;namespacelostechies.daysofrefactoring.samplecode.removemiddleman.after{Public classConsumer{ PublicAccountdataproviderAccountdataprovider {Get;Set; } PublicConsumer (AccountdataproviderDataprovider) {accountdataprovider = Dataprovider; }Public voidGet (intID) {Account account = Accountdataprovider.getaccount (ID); }    }Public classAccountdataprovider{ PublicAccount Getaccount (intID) {//Get Account}    }}

Summary: "Removal of man-in-the-middle objects" can be useful in many cases, especially in code that misuse design patterns, where adapter patterns and proxy patterns in design patterns are associated with each other in the middle class, which is reasonable because the intermediate classes do a lot of things, and the intermediate classes that have no effect should be removed.

Copyright NOTICE: This article for Bo Master http://www.zuiniusn.com original article, without Bo Master permission not reproduced.

Remove the Middleman object