oop - Using an interface/Inheritance as a marker when concrete type represents different choices of which there can only be one -

quite mouth-full of question oo principle i've struggling with. lets have e-commerce app , there concept of payment method, examples creditcard, paypal, apple pay etc. user has choice of payment method select need present them in list on screen , depending on selection used drive ui, presenting different text/images/interactions serialised differently payment request on wire.

here code:

public class paypalpayment : paymentmethod {      public string token;     public string string;  }  public class creditcardpayment : paymentmethod {      public address address;     public creditcard creditcard;  }  interface paymentmethod {  }   public class booking {     public paymentmethod paymentmethod; //generic object      //or      public paypalpayment paypalpayment;     public creditcardpayment creditcardpayment; } 

so in booking class can either have generic payment object referred interface cant underlying type without casting sucks, in reality them don't share common properties doman-wise. alternatively have multiple properties feels bad in different way. user can select 1 payment method others have null or kind of null object, have either query enum or ask each payment method if null. payment method select screen bit more cumbersome cant iterate on generic type have explicitly build list.

in theory add methods paymentmethod interface, such serialise() or ui presentation methods payment methods have in common have implement them in model object don't want in model layer.

overall dont have clean solution in typical object orientated language. wrote in c# apply oo language.

data seems have been segregated away logic in design. consequence, booking has indulge in inappropriate intimacy payment in order behavior take place, hence casting problem.

an idiomatic oo implementation 1/ define clear responsibility , 2/ encapsulate operations , data in same class. can have abstraction on top of family of these classes behavior can called uniformly consumer code.

the strategy aka policy pattern might choice payment.

ui wise, may better avoid using abstractions , have different uis altogether different payment methods. or, have abstract ui payment model concrete implementations know how render themselves.