Jag jobbar med ett väldigt grötigt API och försöker förenkla det lite med en wrapper. Fastnar dock på en liten designfråga. Jag tycker du skall skapa en abstract klass som har allt som Register och Order har gemensamt. Håller helt med. Arv ska alltid betyda "is-a", utan undantag. Det ska aldrig vara ett fel att öht anropa en metod. Designfråga
För att förenkla kan vi säga så att API:et hanterar två objekt register och ordrar. Skillnaden mellan dem är att ordrar består av både huvud och rader.
Nu är det så att det mesta som gäller för register också gäller för ordrar. Därför ärver ordern från registret.
dvs
class register {
...
}
class order : register {
...
}
Problemet är att det ursprungliga API:et inte är konsistent så det finns t.ex. flera olika sätt att radera i registret men bara ett sätt att radera en order.
Exempel:
register.Delete() // raderar aktuell post
register.Delete(string key) // raderar valfri post
men bara
order.Delete() // radera aktuell post
min wrapper har naturligtvis en virituell Delete() funktion så det fungerar men Delete(string) finns ju även i ordern trots att den inte fungerar. I dagsläget har jag gjort alla Delete-funktionerna virituella och i orderklassen ger de ett undantag.
Har funderat på att skapa en mellanklass som i princip är register utan Delete och låta båda ärva från den. Är det en bättre lösning?Sv: Designfråga
Som sedan Register och Order ärver av som du beskriver.Sv:Designfråga
BTW: "virituella" stavas virtuella. =)