window.open页面加载(window.open on page load)

 让我们看看另一个接口驱动抽象工厂的场景 
 
 在开始之前，我们需要明确一个界面指定了需要完成的工作，并对输入和期望输出进行了细微的指示。 也就是说，它并没有强制要求输入和输出都需要明确定义，因为它们也可以被视为合同本身。 如果我们不完全清楚输入和输出结构如何，我们可以使用标记接口 ; 那些没有任何结构的人.. 
 
 比方说，我们有一个购物车，我们需要提供付款选项。 常见的选择是netbanking，信用卡和贝宝。 让我们有这个场景的定义 
 
public interface ICustomerAccountInformation {  }

public interface IPaymentClient {  }  // Identifies whom the payment is intended for

public interface ITransactionDetails : IPaymentClient {  }  // Identifies amount, beneficiary details to be reflected in customer account

public interface IPaymentStatus { }

public interface IPaymentProvider  { 
    IPaymentStatus ProcessPayment(ICustomerAccountInformation customerInfo, ITransactionDetails transaction);

}


public class PayPal : IPaymentProvider  {

    public IPaymentStatus ProcessPayment(ICustomerAccountInformation customerInfo, ITransactionDetails transaction)  {
           /* Open paypal's login page, 
             do its own checks and process payment. 
             Once successfull, send back to referrer with the payment status
           */
    }

public class NetbankingProvider : IPaymentProvider  {

    public IPaymentStatus ProcessPayment(ICustomerAccountInformation customerInfo, ITransactionDetails transaction)  {
           /* Redirect to bank selection
             redirect to bank's login page, 
             do its own checks and process payment. 
             Once successfull, send back to referrer with the payment status
           */
    }
 
 在整个流程中，每个提供者都可以自由地询问所需的任何信息（有些只需要凭证，而另一些则需要OTP作为附加信息）。 他们也根据自己的结构返回状态。 但是，在逻辑层面上，如果付款成功或失败，它们将获取用户的凭证并返回一条消息 
 
 您可以设计工厂独立于任何其他提供商设计。 只需在每个合同上都有标记界面。 
 
 在执行DI代码（比如NInject ）时，使用“ WhenInjectedInto ”或类似的构造将正确的实现注入到每个正在使用的提供程序中。 您的工厂将根据用户的选择提供使用，而不会影响您的核心业务流程。 
 
 DI的主要规则是将非核心业务从核心业务完全抽象出来。 核心业务不应该关心每个提供商的期望，只是想要预测功能。 标记接口最适合这种要求，尤其是在您开始设计但尚未完全清晰的情况下。 您可以稍后改进标记界面，因为您可以更清楚地了解所涉及的过程。 
 
 让我知道你是否需要进一步清晰的设计。 

Lets take in another scenario for interface driven abstract factory
 
Before starting, we need to be clear that an interface specifies what needs to be done, with a subtle indication of input and desired output. That said, it does not enforce that the input and output both need to be well defined, in that, they can also be taken as contracts themselves. If we are not completely clear about what the input and output be structured as, we can use marker interfaces; those without any structure at all..
 
Lets say we have a shopping cart and we need to provide for payment options. The common choices are netbanking, credit cards and paypal. Lets have the definitions of this scenario
 
public interface ICustomerAccountInformation {  }

public interface IPaymentClient {  }  // Identifies whom the payment is intended for

public interface ITransactionDetails : IPaymentClient {  }  // Identifies amount, beneficiary details to be reflected in customer account

public interface IPaymentStatus { }

public interface IPaymentProvider  { 
    IPaymentStatus ProcessPayment(ICustomerAccountInformation customerInfo, ITransactionDetails transaction);

}


public class PayPal : IPaymentProvider  {

    public IPaymentStatus ProcessPayment(ICustomerAccountInformation customerInfo, ITransactionDetails transaction)  {
           /* Open paypal's login page, 
             do its own checks and process payment. 
             Once successfull, send back to referrer with the payment status
           */
    }

public class NetbankingProvider : IPaymentProvider  {

    public IPaymentStatus ProcessPayment(ICustomerAccountInformation customerInfo, ITransactionDetails transaction)  {
           /* Redirect to bank selection
             redirect to bank's login page, 
             do its own checks and process payment. 
             Once successfull, send back to referrer with the payment status
           */
    }
 
In the entire flow, each of the providers are free to ask for whatever information is required (some just take the credentials while others ask for OTP as additional). They also return status back as per their own structure. However, at a logical level, they take user's credentials and return back a message if the payment was successful or not
 
You can design the factories to be independent of any other provider design. Just have the marker interfaces over each contract.
 
When doing the DI code (say NInject), use the "WhenInjectedInto" or similar construct to inject the correct implementation into each provider being used. Your factories will be available for use based on user's selection, without impacting your core business flow. 
 
The main rule of DI is to to entirely abstract out the non-core business from the core one. The core business should not care about what each provider expects, just to have a faint idea about expected functionality. Marker interfaces suit this requirement best, especially when you have started design but are not completely clear. You can later improve the marker interfaces as you get more clarity into the process involved.
 
Let me know if you need further clarity into design.