Prestasie van die gebruik van statiese metodes vs instantiëren die klas met die metodes

Question

Ek is besig met 'n projek in C #. Die vorige programmeerder het nie geweet objekgeoriënteerde programmering, so die meeste van die kode is in groot lêers (ons praat oor 4-5000 lyne) versprei oor tien en soms honderde metodes, maar net een klas. Refactoring so 'n projek is 'n groot onderneming, en so ek het semi-geleer om daarmee saam te leef vir die oomblik.

Wanneer 'n metode wat gebruik word in een van die kode lêers, die klas is aangehaal en dan die metode is 'n beroep op die voorwerp byvoorbeeld.

Ek wonder of daar enige merkbare prestasie boetes in te doen dit op hierdie manier? Sou ek dan maak al die metodes statiese "vir nou" en, bowenal, sal die aansoek voordeel daaruit op enige manier?

Answer 1

Van hier , 'n statiese oproep is 4 tot 5 keer vinniger as die bou van 'n geval elke keer as jy bel 'n geval metode. Maar ons is nog net praat oor tien nano sekondes per oproep, sodat jy dit onwaarskynlik dat enige voordeel sien, tensy jy regtig stywe sirkelroetes uitroep van 'n metode miljoene kere is, en jy kan dieselfde voordeel te kry deur buite die bou van 'n enkele geval wat lus en hergebruik dit.

Aangesien jy wil hê om elke oproep webwerf verander na die nuwe statiese metode gebruik, is jy waarskynlik beter spandeer jou tyd op geleidelik refactoring.

Answer 2

Ek het gehandel oor 'n soortgelyke probleem waar ek werk. Die programmeerder voor my geskep 1 kontroleerder klas waar al die BLL funksies is gestort.

Ons is herontwerp van die stelsel nou en het baie Controller klasse, afhangende van wat hulle veronderstel is om te beheer Bv geskep.

UserController, GeographyController, ShoppingController ...

Binne elke kontroleerder klas hulle statiese metodes wat maak oproepe na kas of die DAL met behulp van die Singleton patroon.

Dit is aan ons gegee 2 belangrikste voordele. Dit is 'n bietjie vinniger (sowat 2-3 keer vinniger maar was nano sekondes hier praat; P). Die ander is dat die kode is baie skoner

d.w.z

ShoppingController.ListPaymentMethods()

in plaas van

new ShoppingController().ListPaymentMethods()

Ek dink dit maak sin om statiese metodes of klasse gebruik as die klas 'n staat nie in stand te hou.

Answer 3

Dit hang af van wat anders daardie voorwerp bevat - as die "voorwerp" is net 'n klomp van die funksies dan is dit waarskynlik nie die einde van die wêreld. Maar as die voorwerp 'n klomp van die ander voorwerpe bevat, dan instantiëren dit gaan roep al hul vervaardigerskampioenskap (en destructors, wanneer dit verwyder) en jy kan geheue fragmentasie kry en so aan.

Dit gesê, dit klink nie soos prestasie is jou grootste probleem op die oomblik.

Answer 4

Jy moet die doelwitte van die herskryf bepaal. As jy wil lekker toetsbare, uit te brei en te onderhou OO kode het dan kan jy probeer om voorwerpe en hul byvoorbeeld metodes gebruik. Na dit alles is Objekgeoriënteerde programing ons hier praat, nie Klas georiënteerde programmering.

Dit is baie maklik om te fake en / of spot voorwerpe wanneer jy klasse wat koppelvlakke implementeer definieer en jy voer byvoorbeeld metodes. Dit maak deeglike eenheid toets vinnige en doeltreffende.

Ook, as jy 'n goeie OO beginsels volg (sien vaste stof by http: //en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 ) en / of gebruik ontwerpspatrone jy sal beslis doen 'n baie instansie gebaseer, koppelvlak gebaseer ontwikkeling, en nie met behulp van baie statiese metodes.

As vir hierdie voorstel:

  

    

Dit lyk dom om my om 'n voorwerp te skep net sodat jy 'n metode kan noem wat     skynbaar geen newe-effekte op die voorwerp (van jou beskrywing Ek neem aan hierdie).

  

Ek sien dit baie in dot netto winkels en aan my dit is strydig met die inkapseling, 'n sleutel OO konsep. Ek moet nie in staat wees om te sê of 'n metode het newe-effekte deur of die metode is staties nie. Asook breek inkapseling dit beteken dat jy sal nodig hê om die verandering van metodes van statiese om byvoorbeeld wees as / wanneer jy dit verander om die newe-effekte het. Ek stel voor jy lees op die oop / toe beginsel vir hierdie een en sien hoe die voorgestelde benadering, hierbo aangehaal, werk met dit in gedagte.

Onthou dat ou kastanje, 'voortydige optimalisering is die wortel van alle kwaad ". Ek dink in hierdie geval beteken dit nie spring deur hoepels met behulp van onvanpas tegnieke (maw Klas georiënteerde programmering) totdat jy weet jy het 'n prestasie kwessie. Selfs dan ontfout die kwessie en kyk vir die mees geskikte.

Answer 5

Statiese metodes is baie vinniger en maak gebruik van 'n veel minder geheue. Daar is hierdie wanopvatting dat dit net 'n bietjie vinniger. Dit is 'n bietjie vinniger, solank jy dit nie op loops. BTW, 'n paar loops kyk klein maar baie is nie omdat die metode oproep wat die lus is ook 'n ander loop. Jy kan die verskil in kode wat voer die lewering van funksies vertel. Baie minder geheue is ongelukkig waar in baie gevalle. 'N geval kan maklik deel van inligting met suster metodes. A statiese metode sal vra vir die inligting wanneer hy dit nodig het.

Maar soos in die ry motors, spoed bring verantwoordelikheid. Statiese metodes het gewoonlik meer parameters as hulle byvoorbeeld eweknie. Omdat 'n geval sorg van kas gedeel veranderlikes sou neem, sal jou byvoorbeeld metodes mooier lyk.

ShapeUtils.DrawCircle(stroke, pen, origin, radius);

ShapeUtils.DrawSquare(stroke, pen, x, y, width, length);

VS

ShapeUtils utils = new ShapeUtils(stroke,pen);

util.DrawCircle(origin,radius);

util.DrawSquare(x,y,width,length);

In hierdie geval, wanneer die instansie veranderlikes gebruik word deur alle metodes meeste van die tyd, byvoorbeeld metodes is redelik moeite werd. Gevalle is nie oor provinsie, dit is oor die deel hoewel gemeenskaplike staat is 'n natuurlike vorm van die deel, hulle is nie dieselfde nie. Algemene reël is dit: as die metode styf gepaard gaan met ander metodes --- hulle mekaar so baie dat hulle as 'n mens genoem word, die ander behoeftes aan te roep word en dat hulle waarskynlik dieselfde koppie water-- deel is lief vir - moet dit byvoorbeeld gedoen word. Statiese metodes vertaal in byvoorbeeld metodes is nie so moeilik. Jy moet net die gedeelde parameters neem en sit dit as byvoorbeeld veranderlikes. Andersom is harder.

Of jy kan 'n proxy klas wat die statiese metodes sal oorbrug maak. Terwyl dit lyk dalk meer ondoeltreffend in teorie te wees, die praktyk vertel 'n ander storie. Dit is omdat wanneer jy dit nodig om 'n DrawSquare keer (of in 'n lus) noem, gaan reguit na die statiese metode. Maar wanneer jy gaan gebruik is dit oor en oor saam met DrawCircle, jy is nou eers gebruik die geval proxy. 'N Voorbeeld is die System.IO klasse File Info (byvoorbeeld) vs lêer (staties).

Statiese metodes is toetsbaar. Trouens, selfs meer toetsbaar as byvoorbeeld 'n keer. Metode GetSum (x, y) sou baie toetsbare om nie net eenheid toets maar load toets, geïntegreerde toets en gebruik toets wees. Byvoorbeeld metodes is goed vir eenhede toetse, maar aaklige vir elke ander toetse (wat meer saak maak as eenhede toetse BTW) wat is die rede waarom ons kry so baie foute deesdae. Die ding wat al die metodes untestable maak is parameters wat nie sin soos (Sender s, EventArgs e) of globale toestand soos DateTime.Now maak nie. Trouens, statiese metodes is so goed in die toetsbaarheid wat jy sien minder foute in C-kode van 'n nuwe Linux verspreiding as jou gemiddelde OO programmeerder (hy is vol s *** Ek weet).

Answer 6

Ek dink jy het gedeeltelik hierdie vraag in die manier waarop jy dit gevra het geantwoord:? Is daar enige merkbare prestasie boetes in die kode wat jy

As die boetes is nie opvallend, moet jy nie noodwendig enigiets te doen nie. (Al is dit vanselfsprekend die kodebasis sou dramtically baat vind by 'n geleidelike refactor in 'n gerespekteerde OO model).

Ek dink wat ek wil sê probeer sê, 'n prestasie probleem is net 'n probleem wanneer jy agterkom dat dit 'n probleem.

Answer 7

Dit lyk dom om my om 'n voorwerp te skep net sodat jy 'n metode wat skynbaar geen newe-effekte op die voorwerp (van jou beskrywing Ek neem aan hierdie) kan noem. Dit lyk vir my dat 'n beter skikking sou wees om 'n paar internasionale voorwerpe het en net gebruik dié. Op dié manier kan jy die veranderlikes wat normaalweg globale sal wees in die toepaslike klasse sodat hulle effens kleiner omvang sit.

Van daar kan jy stadig beweeg die omvang van hierdie voorwerpe aan kleiner en kleiner totdat jy 'n ordentlike OOP ontwerp.

Dan weer, die benadering wat I sal waarskynlik gebruik is anders;.)

Persoonlik, sou ek waarskynlik fokus op strukture en die funksies wat werk op hulle en probeer om hierdie te omskep in klasse met lede bietjie vir bietjie.

As vir die prestasie aspek van die vraag, moet statiese metodes effens vinniger (maar nie veel) omdat hulle nie betrek bou, verby en dekonstruksie 'n voorwerp.

Answer 8

Dit is nie geldig in PHP, Woordeboek Voorwerp Metode is vinniger:
http://www.vanylla.it/tests/static-method-vs -object.php