webForumDet fria alternativet

class- och interfacefundering

5 svar · 394 visningar · startad av doggelito

doggelitoMedlem sedan juni 20003 076 inlägg
#1

Får inte ihop detta riktigt, jag vet vad jag vill ha ut i slutändan men lyckas inte bygga ihop det rätt! :(

Det hela handla om en Order och dess OrderItems.
Dessa vill jag kunna använda mot olika betallösningar, såsom kortbetalning via Samport alt. Svea ekonomi, Kreditor osv.
Jag vill alltså kunna använda mina Order och OrderItem klasser oavsett betalsätt.
Då tänkte jag att ett interface för varje betalsätt vore på sin plats och då använda de olika interfacen beroende på vad kunden valt för betalsätt.
Ett grundexempel på detta ser ut så här:

public class Order, ISveaCreditCardOrder, IKreditorCreditCardOrder
{
     public int ID {get; set; }
     public IList<OrderItem> Items { get; set; }
     public Datetime OrderDate { get; set; }
}

public class OrderItem, ISveaCreditCardOrderItem, IKreditorCreditCardOrderItem
{
     public int ID {get; set; }
     public string Article {get; set; }
     public int Quantity {get; set; }
}
public interface ISveaCreditCardOrder
{
     string Description { get; set; }
     string IList<ISveaCreditCardOrderItem> Items { get; set; }
}

public interface IKreditorCreditCardOrder
{
     string Article { get; set; }
     string IList<IKreditorCreditCardOrderItem> Items { get; set; }
}

//samt interface för varje item.

Det första problemet här är att Items redan är definierat i Order klassen så därför kan jag inte implementera de båda Items som interfacen kräver. En lösning på det är att döpa om samlingarna i interfacen till ex. SveaItems samt KreditorItems.
Men då helt plötsligt så måste jag ju implementera båda dessa nya samlingar i min Order klass så att den innehåller Items, Sveaitems samt KreditorItems.
Alltså 3 samlingar som i grunden innehåller samma OrderItemklass.
Nu börjar det bli snurrigt!

Jag tror jag börjar så i förklaring och i kodväg! :)
Förstår ni problemet? Hur ska Order klassen se ut respektive interfacen?

Det känns i alla fall som om interface är vägen att gå då betallösningarna kräver sina olika typer av egenskaper. :q

NickemannenMedlem sedan aug. 20003 575 inlägg
#2

Detta är helt fel tycker jag.

Vad är det för information som skiljer för respektive order??
Måste extra info läggas till för varje item?

Jag vet inte exakt vad du är ute efter men jag hade haft något liknande såhär.

public IPayment Payment { get; private set; }
public void Pay(IPayment payment);

SveaCreditCardPayment : IPayment
KreditorCredit : IPayment
doggelitoMedlem sedan juni 20003 076 inlägg
#3

Nickemannen skrev:

Detta är helt fel tycker jag.

:)

Nickemannen skrev:

Vad är det för information som skiljer för respektive order??
Måste extra info läggas till för varje item?

Ja, betallösningsleverantörerna tar emot olika parametrar.
En leverantör kan ex. ha: Artikel, pris samt moms i kr (dvs. string, double, double)
En annan kan ha: Artikel, pris samt moms i procent (string, double, int)
Och om man sedan väljer fakturaköp eller delbetalning så tillkommer ett gäng helt andra egenskaper.

Om jag tolkar ditt exempel rätt så hade du alltså byggt en klass för varje betalsätt och inte ett interface!?
Men blir inte det lite kaka på kaka då?
För som jag förstår det så blir väl ex. din SveaCreditCardPayment nästan en exakt kopia av min Order, eller?
Och hur för jag över min Order till att bli en SveaCreditCardPayment?

NickemannenMedlem sedan aug. 20003 575 inlägg
#4

Hmm, tänkte nog lite fel.

Alltså all information som moms, pris delbetalning osv är väl information som skall ligga på Order i vilket fall som helst?

Det du behöver är olika klasser som tolkar din order till att passa betalningen.
Om kunden t.ex. väljer Svea som betalningsmetod så bör du en klass som tolkar order och tar den datan från order som behövs för att klara av en betalning och skickar.

doggelitoMedlem sedan juni 20003 076 inlägg
#5

nickemannen skrev:

Alltså all information som moms, pris delbetalning osv är väl information som skall ligga på Order i vilket fall som helst?

Japp, det anser jag också, och så är det inlagt nu.

Nickemannen skrev:

Det du behöver är olika klasser som tolkar din order till att passa betalningen.

Jag är inte helt hemma när det gäller interfaces men jag har fått för mig att det är just det som är interfacets jobb!?
Men jag kanske fattat dess betydelse fel och att jag behöver föra över min Orderklass till en SveaOrderklass.

Det slog mig i natt när jag låg och funderade:
Skulle man bli hjälpt av att skapa ytterligare ett interface :) som själva webbutiken handhar?
Alltså typ IWebOrder, och det är denna som används runt om i webbutiken.
För då skulle ju orginalklassen Order kunna innehålla 100 parametrar om det skulle behövas utan att dessa synliggörs i webbutiken!?

NickemannenMedlem sedan aug. 20003 575 inlägg
#6

Nja, du vill väl aldrig ladda in 100 parametrar i ditt objekt som du inte använder. Där hade jag bara laddat in den informationen som är användbar just vid orderläggning och fakturering.

För att lösa betalningen så finns det ett par saker du kan göra.
Som sagt på din Order kanske du vill sätta, hur har kunden valt att betala eller betalt, här kan du ha en enum t.ex.

public enum PaymentProviders
{
      Svea,
      Kreditor,
      Visa,
}

Sedan hade jag haft ett interface:

public interface IPaymentProviderService
{
     PaymentProvider PaymentProvider { get; }
     PerformPayment(Order order); //(alternativt om du vill ha payment till något annat så)
     PerformPayment(IPayable item); //(kom inte på ngt bra namn just nu :P)
}

Sedan en PaymentService

public class PaymentService
{
    private IList<IPaymentProviderService> _providers;

    public PaymentService()
    {
           _providers = new List<IPaymentProviderService>();
    }

    public void PayOrder(Order order)
    {
         var paymentProvider = GetPaymentProvider(order.PaymentProvider);
         if(paymentProvider == null)
             ArgumentException("order.PaymentProvider isn't supported");

         paymentProvider.PerformPayment(order);
    }

    private void GetPaymentProvider(PaymentProvider paymentProvider)...

    public void AddProvider(.....).....

    public void RemoveProvider(.....) ....
}
136 ms totalt · 3 externa anrop · v20260731065814-full.30151723
0 ms — hämta forumlista (cache)
0 ms — hämta statistik (cache)
134 ms — hämta tråd, inlägg och bilagor (db)