c#-perintö - onko mahdollista periä kahdesta alaluokasta yhdeksi? (2023)

>

Vastaukset

• 

  1

  Kirjaudu sisään äänestääksesi

  Ensinnäkin: et voi periä useista luokista. Ainoa asia, jonka voit tehdä ja sinun pitäisi tehdä, on ottaa käyttöön useita rajapintoja.

  Mutta tärkeämpi kysymys on: Mitä yrität saavuttaa? Mikä on yleistavoitteesi tässä?

  Koska kuvauksesi kuulostaavierailijakuvio. Tässä on myös hyvä videokuvaus yksinkertaisesta, suoraviivaisesta käyttötapauksesta (no, se näyttää periaatteessa ongelman, kun tarkastelet sitä testinäkökulmasta):Puhdas koodi puhuu – perinnöllisyys, polymorfismi ja testaus.

  Joten sopivan perinnön valitseminen käyttöliittymän avulla ratkaisee ongelmasi.

  
  

  • Muokannut Stephen Hoffman Lauantai 27. lokakuuta 2012 klo 11.27
  • Merkitsi vastaukseksi jmatty2000 lauantaina 27. lokakuuta 2012 klo 14:06

  See Also

  C#-perintö (esimerkein)

  Lauantai 27. lokakuuta 2012 klo 11.26

Kaikki vastaukset

• 

  1

  Kirjaudu sisään äänestääksesi

  Ensinnäkin: et voi periä useista luokista. Ainoa asia, jonka voit tehdä ja sinun pitäisi tehdä, on ottaa käyttöön useita rajapintoja.

  Mutta tärkeämpi kysymys on: Mitä yrität saavuttaa? Mikä on yleistavoitteesi tässä?

  Koska kuvauksesi kuulostaavierailijakuvio. Tässä on myös hyvä videokuvaus yksinkertaisesta, suoraviivaisesta käyttötapauksesta (no, se näyttää periaatteessa ongelman, kun tarkastelet sitä testinäkökulmasta):Puhdas koodi puhuu – perinnöllisyys, polymorfismi ja testaus.

  Joten sopivan perinnön valitseminen käyttöliittymän avulla ratkaisee ongelmasi.

  
  

  • Muokannut Stephen Hoffman Lauantai 27. lokakuuta 2012 klo 11.27
  • Merkitsi vastaukseksi jmatty2000 lauantaina 27. lokakuuta 2012 klo 14:06

  Lauantai 27. lokakuuta 2012 klo 11.26

• 

  1

  Kirjaudu sisään äänestääksesi

  Katso tämä viesti saadaksesi täydellisen keskustelun aiheesta

  http://social.msdn.microsoft.com/Forums/en/csharpgeneral/thread/340d80d9-e2cf-4f07-a1d4-29b0500830fb

  jdweng

  Lauantai 27. lokakuuta 2012 klo 11.39

• 

  Kirjaudu sisään äänestääksesi

  Hei Stefan ja Joel

  Periaatteessa yrittäisin yhdistää manuaaliset tapahtumat ja automaattiset tapahtumat yhteen toiseksi luetteloksi. Olen itse asiassa jo kirjoittanut ohjelmani, joka rakentaa luettelon automaattisista tapahtumista yhdessä manuaalisten tapahtumien kanssa. Lopulta käytän luetteloiden yhdistämistä tehdäkseni summat ja suodattaakseni tietyt tilit sen mukaan, mitkä tilitapahtumat käyttäjä haluaa nähdä. Näen käyttäväni Linqiä yhdistetyn luettelon toimintojen suorittamiseen, mistä on myös hyötyä.
  

  Toistaiseksi ratkaisuni sisältää uuden alaluokan luomisen perimällä Automated Transactions -alaluokkakannasta ja lisäämällä ylimääräisiä ominaisuuksia manuaalisesta luokasta (koska manuaalisesta alaluokasta on vähemmän lisättävää.

  On hassua, että mainitsit Use-Casen, koska luen juuri tällä hetkellä kirjaa tästä:-

  Dan Clarkin C#-olioohjelmoinnin aloittaminen

  Kirja alkaa suosittelemalla, että piirrät käyttötapauskaavion, luokkakaaviot ja käyttöliittymäkaaviot ennen koodin kirjoittamisen aloittamista.

  Käyn katsomassa linkkejäsi.

  Kiitos toistaiseksi

  Matta

  p.s. Tämä on ratkaisuni yhdistetyn alaluokan luomiseen, jos et ymmärtänyt mitä en tarkoita yllä (se sisältää vain yhden ylimääräisen ominaisuuden:

  public class Manuaal.AutomaattinenYhdistetty: Automaattinen { yksityinen merkkityyppiAorM; public ManualandAutomaticCombined() { } public char TypeAorM { get { return typeAorM; } set { typeAorM = arvo; } } }

  
  

  • Muokannut jmatty2000 lauantaina 27. lokakuuta 2012 klo 12:19

  lauantaina 27. lokakuuta 2012 klo 12:17

• 

  1

  Kirjaudu sisään äänestääksesi

  Yksi tapa "toteuttaa useita perintöjä" on Generics. Tässä esimerkki ideasta.

  class Ohjelma { static void Main(merkkijono[] args) { Tapahtumatapahtuma = new AutomaticTransaction(); PerformTransaction(tapahtuma); Console.ReadLine(); } yksityinen static void PerformTransaction(Tapahtumatapahtuma) { var tapahtumanhallinta = new TransactionManager(new AutomaticTransactionManager()); tapahtumanhallinta.Suorita(tapahtuma); } }

  Tässä on esimerkkiluokkia yllä olevan toteuttamiseksi.

  julkinen luokka Tapahtuma : ITtransaction { suojattu tapahtuma() { } } julkinen käyttöliittymä ITtransaction { } public class ManualTransaction : Tapahtuma { } public class Automaattinen tapahtuma : Tapahtuma { } julkinen delegoitu objekti PerformTransaction(Tapahtuman transaktio, IPerformTransaction transactor); public class TransactionException : Poikkeus { } julkinen käyttöliittymä IPerformTransaction { void PerformAsyncTransaction(Tapahtumatapahtuma); } public class AutomaticTransactionManager : TransactionManagerBase { //julkinen ohitus void PerformAsyncTransaction(Transaction Transaction) // //{ // // siirtää tapahtuman AutomaticTransactioniin? // PerformAsyncTransaction(transaction); //} suojattu ohitusobjekti Execute(Tapahtumatapahtuma, IPerformTransaction transactor) { Console.Write("Automaattinen tapahtuma oli "); // automaattinen toteutus menee tähän paluutapahtuma; // suorita tapahtuma täällä. } } julkinen abstrakti luokka TransactionManagerBase : IPerformTransaction { yksityinen objektitapahtumaReturnValue; suojattu virtuaalinen void PerformAsyncTransaction(Tapahtumatapahtuma, PerformTransaction executor) { AsyncCallback callback = PerformTransactionCallback; executor.BeginInvoke(transaction, this, callback, executor); } suojattu virtuaalinen void PerformTransactionCallback(IAsyncResult ar) { yritä { PerformTransaction executor = (PerformTransaction)ar.AsyncState; this.transactionReturnValue = executor.EndInvoke(ar); // tapahtumapoikkeukset on kiinni täällä! } catch (Exception ex) { if ( ex.Message == "jokin poikkeus heitettiin asynkronoinnin aikana" ) { Console.Write("Epäonnistui."); heittää uusi TransactionException(); // uudelleenpoikkeus soittajalle } } vihdoin { TransactionSuccessful(); } } private void TransactionSuccessful() { Console.WriteLine("Onnistui."); // onnistunut tapahtumakoodi } public virtual void PerformAsyncTransaction(Tapahtumatapahtuma) { SuoritaAsyncTransaction(transaction, Execute); //Suorita(tapahtuma, tämä); } suojattu virtuaaliobjekti Execute(Tapahtumatapahtuma, IPerformTransaction transactor) { // automaattinen perustoteutus menee tähän Console.Write("Abstrakti tapahtuma oli "); palautustapahtuma; // suorita tapahtuma täällä. } } public class TransactionManager missä T : IPerformTransaction { yksityinen T-tapahtuma; public TransactionManager(T transactor) { this.transactor = transactor; } julkinen objekti Execute(Tapahtumatapahtuma) { transactor.PerformAsyncTransaction(transaction); palautustapahtuma; } }

  
  

  'Rudy = 8^D

  Merkitse parhaat vastaukset vastauksiksi. "Tietokoneiden huijaaminen vuodesta 1971."

  http://thesharpercoder.com/

  
  

  • Muokannut Rudedog2 lauantaina 27. lokakuuta 2012 klo 15:59 oikea ääretön silmukka

  lauantaina 27. lokakuuta 2012 klo 14:01

• 

  Kirjaudu sisään äänestääksesi

  Hei kaverit

  Kiitos avustasi täällä. En ole vielä oppinut paljoakaan käyttöliittymistä, mutta kuulostaa todella hyödylliseltä.

  Olen yrittänyt lukea luvun aiheesta kirjasta, mutta en ole vielä varma, mistä ne kertovat.

  Kiitos samoin

  Pysyn nyt vain perusasioissa (mielestäni).

  Kippis

  Matta

  lauantaina 27. lokakuuta 2012 klo 14:05

• 

  Kirjaudu sisään äänestääksesi

  Mikset vain tee luettelostasi List? Tämän avulla voit lisätä esiintymiä mistä tahansa johdetuista luokista. Jos sinun on käsiteltävä kohteita, voit käyttää "is"-avainsanaa erottamaan automaattinen ja manuaalinen.

  Ilmeisesti tällä on rajoituksia, koska Rudyn vastausten lukeminen saa sinut tietoiseksi. Pidemmällä aikavälillä se on suunta, johon sinun pitäisi mennä.

  Terveisin David R
  ----------------------------------------------------------------
  Hienoa olioorientoidussa koodissa on, että se voi saada pienet, yksinkertaiset ongelmat näyttämään suurilta, monimutkaisilta.
  Olio-ohjelmointi tarjoaa kestävän tavan kirjoittaa spagettikoodia. - Paul Graham.
  Jokainen ohjelma muuttuu lopulta rokokooksi ja sitten raunioiksi. - Alan Perlis
  Ainoa kelvollinen koodin laadun mitta: WTFs/minuutti.

  lauantaina 27. lokakuuta 2012 klo 18.59

• 

  Kirjaudu sisään äänestääksesi

  Tässä on (erittäin?) karkea opas esimerkkiäsi käyttäen. Tiedät, että luokka voi periä toiselta ja saa mitä tahansa perustoteutusta "ilmaiseksi" (eli sinun ei tarvitse toteuttaa sitä uudelleen). Joten Automaattinen ja Manuaalinen -luokat saavat Transaction-luokkaan kirjoitetut kentät ja menetelmät. Huono puoli: voit periä vain yhdeltä pohjalta.

  Käyttöliittymä on jossain määrin kuin perusta, mutta se ei toteuta menetelmiä. Johdettujen luokkien on toteutettava ne. Miksi vaivautua? Jos Transactions oli käyttöliittymä, sinulla voisi olla List ja lisätä kohteita mistä tahansa luokasta, joka toteuttaa käyttöliittymän. Haittapuoli: sinun on otettava menetelmät käyttöön kaikissa johdetuissa luokissa, etkä saa mitään "ilmaiseksi".

  Yksi tapa ajatella sitä on, että jos luokka (Manuaalinen) perii toiselta (Tapahtuma), se (Manuaalinen) on Transaction. Jos se toteuttaa rajapinnan, se lupaa, että rajapinnan menetelmät toteutetaan.

  Haluaisin katsoa käyttöliittymiä, jotka ovat todella perustavanlaatuisempia ja hyödyllisempiä kuin perintö. Yksi hyvä lähde, joka käyttää niitä, on "Head First Design Patterns" - mutta älä kirjoita koodia vain käyttääksesi kuvioita, vaan käytä niitä suunnittelussa.

  Terveisin David R
  ----------------------------------------------------------------
  Hienoa olioorientoidussa koodissa on, että se voi saada pienet, yksinkertaiset ongelmat näyttämään suurilta, monimutkaisilta.
  Olio-ohjelmointi tarjoaa kestävän tavan kirjoittaa spagettikoodia. - Paul Graham.
  Jokainen ohjelma muuttuu lopulta rokokooksi ja sitten raunioiksi. - Alan Perlis
  Ainoa kelvollinen koodin laadun mitta: WTFs/minuutti.

  lauantaina 27. lokakuuta 2012 klo 19.13

• 

  Kirjaudu sisään äänestääksesi

  Näen, että jotkut näiden levyjen hienoimmista ovat jo vastanneet. Joskus on parasta ajatella polymorfismia ja sen merkitystä. Poly-Morph-ism = monta morfia, yksinkertaisesti sanottuna kyky näyttää joltakin muulta. Pidän perinnöstä morfismin pystysuuntaisena tyylinä, jossa korkein (tai alin, riippuen siitä, miten sitä tarkastellaan) yhteinen kerros on objekti. Objektista kaikki muu johdetaan lisäämällä kenttiä, ominaisuuksia ja menetelmiä. Sinun tapauksessasi sinulla voi olla tapahtumien perusluokka, joka sisältää kaikki automaattisen ja manuaalisen tapahtuman yhteiset piirteet, mutta "vertikaalista" ja sen suunnittelusta riippuen sinulla voi todellakin olla sekä manuaalisia että automaattisia tapahtumatyyppejä, kuten tämä:

  Tapahtuma (juuri/perusluokka)

  Manuaalinen tapahtuma

  Automaattinen tapahtuma

  Jos luokkasi heierarkia seurasi yllä olevaa mallia, automaattinen tapahtuma voi olla myös manuaalinen tapahtuma, mutta ei päinvastoin! Upcasting tai downcasting, voit muuttua mitä haluat!

  CustomerTransAction : Tapahtuma{//Yleiset kentät, ominaisuudet ja menetelmät molemmille tyypeille, joita noudatetaan.}ManualTransAction : CustomerTransAction{//Sisältää vain ManualTransaction-kenttiä, ominaisuuksia ja menetelmiä. }AutomaticTransAction : ManualTranAction{//sisältää vain automaation, mutta sillä on pääsy manuaaliseen käyttöön seuraavasti: var mantransaction = (ManualTransaction) this;}

  Yllä oleva esimerkki on ongelmallisempi ylläpitää, eikä AutomatTransactionsille välttämättä koskaan ole syytä muuttua manuaalisiksi tapahtumiksi.

  Liitännät ovat sellaisia, joihin haluan viitata, ja niissä on vaakasuuntainen suojaus, koska näemme usein tapauksia, joissa rajapinta siirretään menetelmään tai ominaisuuteen, jonka luokka sisältää. Se voisi näyttää tältä:

  public class CustomerTransaction{private ManualTransaction {get;set;}private AutomaticTransaction {get;set;}julkinen tapahtuma (AutomaticTransaction auto) AutomaticTransaction = auto;}julkinen tapahtuma (ManualTransaction man){ ManualTransaction = mies;}//...muita juttuja täällä}

  Yllä olevassa koodissa CustomerTransaction voi sisältää joko automaattisen tai manuaalisen tapahtuman! Mutta huomaa, että se vain sisältää ne, ei peri niitä.

  Tämä on parempi tehdä, koska se antaa sinulle enemmän joustavuutta muuttaa ajan myötä.

  Stefan mainitsee vierailijakuvion, joka on tyyppiinjektio, jossa vierailija tulee sisään vain sallitun tyypin kanssa. Todella vahva malli opeteltavaksi.

  Interface-pohjainen ohjelmointi "Favors Composition", joka on Martin Fowlerin usein tekemä kohta. Se on parempi tapa edetä.

  JP Cowboy Coders Unite!

  Sunnuntai 28. lokakuuta 2012 klo 1:20

• 

  Kirjaudu sisään äänestääksesi

  Koodin perusongelma on huolenaiheiden erottelun puute. Onko tapahtuma jotain, joka sisältää tietoja, vai onko se jotain, joka käsittelee tietoja? Tapahtuman ei pitäisi osata tehdä molempia. Alkuperäinen suunnittelu haluaa Tapahtuman osaavan käsitellä itsensä.

  Ehkä Transaction-luokka tarvitsee toisen luettelon määrittelemän kentän, TransactionType, Automatic tai Manual. Tämän ominaisuuden avulla voidaan sitten kutsua oikeantyyppinen TransactionManager, automaattinen tai manuaalinen.

  Rudy = 8^D

  Merkitse parhaat vastaukset vastauksiksi. "Tietokoneiden huijaaminen vuodesta 1971."

  http://thesharpercoder.com/

  
  

  • Muokannut Rudedog2 Sunnuntai 28. lokakuuta 2012 klo 9.27

  Sunnuntai 28. lokakuuta 2012 klo 9.22

• 

  Kirjaudu sisään äänestääksesi

  Hei Rudedog2

  Kiitos sinulle ja kaikille, jotka autat minua. Osa siitä, mistä puhut, on minulle täysin uutta.

  Tiedän, että kysyit, sisältääkö tapahtuma dataa tai jotain, joka käsittelee tietoja – sen ei pitäisi tehdä molempia.

  Ehkä ensi kerralla selitän enemmän siitä, miksi kysyn ja että olen melko uusi OOP-ohjelmoinnin parissa. Joka tapauksessa yritän suunnitella henkilökohtaista tilipakettia (vain kotiprojekti minulle). Ongelmana on, että manuaalinen tapahtuma voi olla vain kertamaksu esimerkiksi ruoasta tai bensiinistä. Kolikon toisella puolella (ehkä) automaattiset tapahtumat ovat jotain, joka voidaan määrittää vaikuttamaan kerran kuukaudessa, esim. asuntolaina, kaasu, sähkö jne. Kun käyttäjä luo tilit, automaattiset tapahtumat on lisättävä heti alussa, jotta ne tapahtuvat tulevaisuudessa (eli tapahtuvat kerran kuukaudessa). Tiliohjelmiston on myös annettava käyttäjän katsoa tulevaisuuteen nähdäkseen, kuinka paljon rahaa jää jäljelle kaikkien automatisoitujen tapahtumien jälkeen. Monimutkaisuuden lisäämiseksi käyttäjän tulisi myös pystyä päivittämään kaikki tulevat automatisoidut tapahtumat milloin tahansa, esim. tv-lupalasku voi nousta tai tapahtuma voi tapahtua eri päivänä.

  Varmasti mielenkiintoista. Minulla on tällä hetkellä henkilökohtaisten tilien ohjelmistopaketti, joka tekee tämän jo, mutta kestää iät aikaa selata eri tilien välillä, mikä on vain merkki huonosta suunnittelusta, vaikka myyjät eivät koskaan myönnä sitä. (Tiedämme, että voimme tehdä parempaa työtä! :) )
  

  Kippis

  Matta

  Sunnuntai 28. lokakuuta 2012 klo 17:58