Tiedän, että perusmenetelmän kutsumisesta ohitetun menetelmän sisällä on kysyttävää, kuten tämä . Mutta entä jos ohitettu menetelmä kutsuu vain perusluokkaa? Onko tämä huono / hyvä kunnia? Näyttää vain oudolta, miksi ohittaa menetelmän vain tukikohdan kutsumiseksi?
Katso esimerkiksi:
public class BaseClass { virtual public void Method1() { //Do stuff } } public class InheritingClass : BaseClass { override public void Method1() { base.Method1(); } } Kommentit
- Sillä ei ole tarkoitusta ja vain sekoitetaan koodi, joten päästä eroon.
- @DavidArno että ' mitä ajattelin myös, varmistaen vain, että ' ei ollut siihen syytä ennen kuin tein niin
- Ihanteellisessa maailmassa sovellus kattaa yksikötestit, joten voit poistaa sen, ja kun kaikki testit vielä läpäisivät, ' tiedät, että sitä ei tarvita '. Emme kuitenkaan <
asu aina ihanteellisessa maailmassa, joten oli järkevää kysyä 🙂
vastaus
Mutta entä jos ohitettu menetelmä kutsuu vain perusluokkaa? Onko tämä huono / hyvä muotoilu?
Huono suunnittelu ? Ei, melko huono toteutus. Se on harhaanjohtavaa huolto-ohjelmoijaa varten. Kun en näe ohitusta, tiedän, että tukiasemaa kutsutaan. Ohitus kertoo minulle, että on jotain erilaista, vaikka tukikohta kutsutaan myös sinne.
Ohituksen vaatiminen tukikohdan kutsumiseksi ilman mallia on huono muotoilu
Viitattu ketju – suosituin vastaaja
Oma ensimmäinen reaktioni skandinaaviseen ohitukseen malli on: KAAVAN KOODAAMINEN! Näyttää siltä, että minun on pakko lukea kaikki tämä ja sitten lisää varmistaakseni, että ”alikäyttäytyminen” ei riko koodiani ja päinvastoin.
Template Method Pattern on hyvä tapa ilmaista muuttujakoodi suuremmassa koodivirrassa ja varmistaa oikea suoritusjärjestys.
Kokemukseni mukaan aliluokalle on niin tyypillistä tietää mitä perusta-ilmoitettuja menetelmiä soittaa ja järjestyksessä Ota kasa kourallinen alaluokkia, joilla kaikilla on sama cut-n-paste-ohjausrakenne, lisää 5 vuoden huolto; nyt ymmärrät, miksi pidän parempana 101 todisteesta Villi Turkki .
P.S. Kaikki tämä on yksi suuri syy, miksi haastan interface iden liikakäyttöä luokkien abstract sijaan.
Kommentit
- Rajapintojen liiallinen käyttö C #: ssa johtuu todennäköisesti siitä, ettei halua kahlita toteuttajaa kyseiseen abstraktiin perusluokkaan. Käyttöliittymän avulla toteuttaja voi toteuttaa toisen perusluokan eikä vain tuon tietyn abstraktin luokan. Se riippuu kuitenkin paljon olosuhteista. Minusta on hyvä käytäntö olla sekä
IFoo-käyttöliittymä ettäFooBase-luokka, joka toteuttaaIFookäyttöliittymä, jossa abstraktit menetelmäpyynnöt rekvisiittaa varten. Ehkä heittää myös ctor.
Vastaa
IMO, virtual -menetelmillä on perusluokassa hyvin yksinkertainen toteutus. Vaikka me override määritelmän virtual -menetelmälle lapsiluokassa, voimme silti kutsua virtual -menetelmä (perustoteutuksella), vaikka se on järkevää eikä vaikuta overridden -menetelmän suunniteltuun käyttäytymiseen lapsiluokassa.
Esimerkiksi BaseCalculator tekee todellisen työn. Laskin koristaa BaseCalculator-kirjastoa laajentamalla sitä.
public class BaseCalculator { public virtual T Add<T>(T number01, T number02) { return number01 + number02; } } public class Calculator: BaseCalculator { public override T Add<T>(T number01, T number02) { Console.WriteLine(number01 + " | " + number02); var result = base.Add<int>(1, 3); Console.WriteLine("Result: "+ result); return result; } } K: Entä jos ohitettu menetelmä kutsuu vain perusluokkaa?
A: Sinun tapauksessasi perusluokan menetelmä on virtual, meidän ei tarvitse override sitä, ennen kuin haluamme muuttaa sen käyttäytymistä.
K: Onko tämä huono / hyvä kunnia?
A: Kyllä, suunnittelu saattaa olla huono, koska se voi sekoittaa lähdekooditiedoston, kun lisätään tarpeettomia ohituksia.
K: Näyttää vain oudolta, miksi ohittaa menetelmän vain tukikohdan kutsumiseksi?
A: BaseCalculator tekee todellisen työn . Laskin koristaa BaseCalculator-kirjastoa laajentamalla sitä.
Toivottavasti se auttaa!