Programmēšana

Dizains ar statiskiem elementiem

Lai gan Java lielā mērā ir orientēta uz objektu, tā nav a tīrs uz objektu orientēta valoda. Viens no iemesliem, kāpēc Java nav vērsta tikai uz objektu, ir tas, ka ne viss tajā esošais ir objekts. Piemēram, Java ļauj deklarēt primitīvu tipu mainīgos (int, peldēt, būlautt.), kas nav objekti. Java ir statiski lauki un metodes, kas ir neatkarīgi un atsevišķi no objektiem. Šajā rakstā ir sniegti padomi par statisko lauku un metožu izmantošanu Java programmā, vienlaikus saglabājot objektos orientētu dizainu.

Klases kalpošanas laikam Java virtuālajā mašīnā (JVM) ir daudz līdzību ar objekta kalpošanas laiku. Tāpat kā objektam var būt stāvoklis, ko attēlo tā instances mainīgo vērtības, klasei var būt stāvoklis, ko attēlo tā klases mainīgo vērtības. Tāpat kā JVM pirms inicializācijas koda iestatīšanas instances mainīgajiem iestata noklusējuma sākotnējās vērtības, JVM pirms inicializācijas koda izpildes klases mainīgajiem nosaka noklusējuma sākotnējās vērtības. Tāpat kā objekti, arī klases var būt savākti atkritumi, ja uz tām vairs neattiecas darbojošā lietojumprogramma.

Neskatoties uz to, pastāv ievērojamas atšķirības starp klasēm un objektiem. Varbūt vissvarīgākā atšķirība ir veids, kā tiek izmantotas instances un klases metodes: instanču metodes ir (lielākoties) dinamiski saistītas, bet klases metodes ir statiski saistītas. (Trīs īpašos gadījumos gadījumu metodes nav dinamiski saistītas: privātu instanču metožu piesaiste, tajā metodes (konstruktori) un aicinājumi ar super atslēgvārds. Plašāku informāciju skatiet sadaļā Resursi.)

Vēl viena atšķirība starp klasēm un objektiem ir datu slēpšanās pakāpe, ko piešķir privātie piekļuves līmeņi. Ja instances mainīgais tiek pasludināts par privātu, tam var piekļūt tikai instances metodes. Tas ļauj nodrošināt instances datu integritāti un padarīt objektus drošus. Pārējā programma nevar tieši piekļūt šiem instances mainīgajiem, taču, lai manipulētu ar instances mainīgajiem, tām ir jāiziet cauri instanču metodēm. Cenšoties panākt, lai klase izturētos kā labi izstrādāts objekts, varat padarīt klases mainīgos privātus un definēt klases metodes, kas ar tiem manipulē. Neskatoties uz to, šādā veidā jūs negūstat tik labu garantiju par pavedienu drošību vai pat datu integritāti, jo noteikta veida kodam ir īpaša privilēģija, kas viņiem dod tiešu piekļuvi privāto klašu mainīgajiem: instanču metodēm un pat instances iniciatoriem. mainīgajiem, var tieši piekļūt šiem privāto klases mainīgajiem.

Tātad statiskajiem laukiem un klašu metodēm, lai arī daudzos aspektos tie ir līdzīgi objektu instanču laukiem un metodēm, ir būtiskas atšķirības, kurām vajadzētu ietekmēt veidu, kā jūs tos izmantojat dizainā.

Nodarbības ar priekšmetiem

Veidojot Java programmas, jūs, visticamāk, saskarsieties ar daudzām situācijām, kurās jūtat vajadzību pēc objekta, kas darbojas kaut kādā veidā kā klase. Piemēram, jūs varat vēlēties objektu, kura kalpošanas laiks atbilst klases ilgumam. Vai arī jūs varētu vēlēties objektu, kas, tāpat kā klase, ierobežo sevi ar vienu instancē noteiktā vārda telpā.

Šādās dizaina situācijās var būt vilinoši izveidot klasi un izmantot to kā objektu, lai definētu klases mainīgos, padarītu tos privātus un noteiktu dažas publiskas klases metodes, kas manipulē ar klases mainīgajiem. Tāpat kā objektam, arī šai klasei ir stāvoklis. Tāpat kā labi izstrādāts objekts, arī mainīgie, kas nosaka stāvokli, ir privāti, un ārējā pasaule var ietekmēt šo stāvokli tikai, atsaucoties uz klases metodēm.

Diemžēl ar šo pieeju "klase kā objekts" pastāv dažas problēmas. Tā kā klases metodes ir statiski saistītas, jūsu klases objekts neizbaudīs polimorfisma un augšupvērstās elastības priekšrocības. (Polimorfisma un dinamiskās saistīšanās definīcijas sk. Dizaina tehnikas rakstā Kompozīcija pret mantojumu.) Polimorfismu padara iespējamu un noderīgu, izmantojot dinamisku saistīšanu, taču klases metodes nav dinamiski saistītas. Ja kāds apakšklasē iekļauj jūsu klasi kā objektu, viņš to nevarēs ignorēt savas klases metodes, deklarējot klases metodes ar tādu pašu nosaukumu; viņi varēs tikai paslēpties tos. Kad tiek izmantota viena no šīm atkārtoti definētajām klases metodēm, JVM atlasīs metodes ieviešanu, kas izpildāma nevis pēc objekta klases izpildes laikā, bet pēc mainīgā veida sastādīšanas laikā.

Turklāt pavedienu drošība un datu integritāte, kas tiek rūpīgi sasniegta, izmantojot klases metodes savā klasē, ir kā no salmiem būvēta māja. Jūsu pavedienu drošība un datu integritāte tiks garantēta, kamēr visi izmantos klases metodes, lai manipulētu ar klases mainīgajos saglabāto stāvokli. Bet neuzmanīgs vai bezjēdzīgs programmētājs, pievienojot vienu gadījuma metodi, kas tieši piekļūst jūsu privāto klases mainīgajiem, netīšām pļāpā un uzpūš un aizpūš jūsu pavedienu drošību un datu integritāti.

Šī iemesla dēļ mana galvenā vadlīnija attiecībā uz klases mainīgajiem un klases metodēm ir:

Neapstrādājiet klases kā priekšmetus.

Citiem vārdiem sakot, neveidojiet klases statiskos laukus un metodes tā, it kā tie būtu objekta instances lauki un metodes.

Ja vēlaties kādu stāvokli un uzvedību, kura kalpošanas laiks atbilst klases ilgumam, objekta simulēšanai neizmantojiet klases mainīgos un klases metodes. Tā vietā izveidojiet faktisko objektu un izmantojiet klases mainīgo, lai turētu atsauci uz to, un klases metodes, lai nodrošinātu piekļuvi objekta atsaucei. Ja vēlaties pārliecināties, ka vienā nosaukuma telpā pastāv tikai viens stāvokļa un uzvedības gadījums, nemēģiniet izveidot klasi, kas simulē objektu. Tā vietā izveidojiet a vienskaitlis - objektam, kuram katrā nosaukuma vietā ir tikai viens gadījums.

Tātad, kas ir klases biedri?

Manuprāt, labākais domāšanas veids, kas jāattīsta, izstrādājot Java programmas, ir domāt par objektiem, objektiem, objektiem. Koncentrējieties uz lielisku objektu dizainu un domājiet par klasēm galvenokārt par objektu rasējumiem - struktūru, kurā definējat eksemplāru mainīgos un gadījumu metodes, kas veido jūsu labi izstrādātus objektus. Bez tam jūs varat domāt par nodarbībām kā par dažu īpašu pakalpojumu sniegšanu, kurus objekti nevar nodrošināt vai nevar sniegt tik eleganti. Domājiet par klasēm kā:

  • pareiza vieta, kur definēt "lietderības metodes" (metodes, kas ievada un nodrošina izvadi tikai caur nodotajiem parametriem un atgriešanās vērtību)
  • veids, kā kontrolēt piekļuvi objektiem un datiem

Lietderības metodes

Metodes, kas manipulē ar objekta vai klases statusu, ko es saucu par “lietderības metodēm”. Lietderības metodes tikai atgriež kādu vērtību (vai vērtības), kas aprēķināta tikai no datiem, kas parametram nodoti metodei. Jums vajadzētu padarīt šādas metodes statiskas un ievietot tās klasē, kas ir visciešāk saistīta ar metodes sniegto pakalpojumu.

Lietderības metodes piemērs ir String copyValueOf (char [] dati) klases metode Stīga. Šī metode rada tā izvadi, tipa atgriešanās vērtību Stīga, tikai no tā ievades parametra, masīvs chars. Tā kā copyValueOf () nedz lieto, nedz ietekmē jebkura objekta vai klases stāvokli, tā ir noderīga metode. Tāpat kā visām lietderības metodēm vajadzētu būt, copyValueOf () ir klases metode.

Tātad viens no galvenajiem klases metožu izmantošanas veidiem ir lietderības metodes - metodes, kas atgriež izlaidi, kas aprēķināta tikai no ievades parametriem. Citi klases metožu pielietojumi ietver klases mainīgos.

Klases mainīgie datu slēpšanai

Viens no objektorientētās programmēšanas pamatnoteikumiem ir datu slēpšana - piekļuves ierobežošana datiem, lai samazinātu atkarību starp programmas daļām. Ja konkrētam datu gabalam ir ierobežota piekļuve, šie dati var mainīties, nesalaužot tās programmas daļas, kuras nevar piekļūt datiem.

Ja, piemēram, objekts ir vajadzīgs tikai noteiktas klases gadījumiem, atsauci uz to var saglabāt privātas klases mainīgajā. Tas visiem šīs klases gadījumiem nodrošina ērtu piekļuvi šim objektam - gadījumi to vienkārši izmanto tieši -, bet neviens cits kods, kas atrodas citur programmā, to nevar piekļūt. Līdzīgā veidā varat izmantot pakotnes piekļuvi un aizsargātus klases mainīgos, lai samazinātu to objektu redzamību, kuri ir koplietojami visiem paketes un apakšklases dalībniekiem.

Publiskās klases mainīgie ir cits stāsts. Ja publiskās klases mainīgais nav galīgs, tas ir globāls mainīgais: tas nejaukais uzbūve, kas ir pretstats datu slēpšanai. Publiskās klases mainīgajam nekad nav attaisnojuma, ja vien tas nav galīgs.

Galīgie publiskās klases mainīgie, neatkarīgi no tā, vai tie ir primitīva tipa vai objekta atsauce, kalpo noderīgam mērķim. Primitīvu vai tipu mainīgie Stīga ir vienkārši konstantes, kas kopumā palīdz padarīt programmas elastīgākas (vieglāk maināmas). Kodu, kurā tiek izmantotas konstantes, ir vieglāk mainīt, jo nemainīgo vērtību var mainīt vienā vietā. Atsauces tipu publiskie gala klases mainīgie ļauj nodrošināt globālu piekļuvi objektiem, kas nepieciešami globāli. Piemēram, System.in, System.out, un System.err ir publiski gala klases mainīgie, kas nodrošina globālu piekļuvi standarta ievades un kļūdu plūsmām.

Tādējādi galvenais veids, kā apskatīt klases mainīgos, ir kā mehānisms, lai ierobežotu mainīgo vai objektu pieejamību (tas nozīmē, lai paslēptu). Kombinējot klases metodes ar klases mainīgajiem, varat ieviest vēl sarežģītākas piekļuves politikas.

Klases metožu izmantošana ar klases mainīgajiem

Papildus tam, ka darbojas kā lietderības metodes, klases metodes var izmantot, lai kontrolētu piekļuvi klases mainīgajos saglabātajiem objektiem, it īpaši, lai kontrolētu objektu izveidi vai pārvaldību. Divi šāda veida klases metodes piemēri ir setSecurityManager () un getSecurityManager () klases metodes Sistēma. Lietojumprogrammas drošības pārvaldnieks ir objekts, kas, tāpat kā standarta ievades, izvades un kļūdu straumes, ir nepieciešams daudzās vietās. Atšķirībā no standarta I / O straumes objektiem, atsauce uz drošības pārvaldnieku netiek glabāta publiskajā gala klases mainīgajā. Drošības pārvaldnieka objekts tiek glabāts privātas klases mainīgajā, un set and get metodes ievieš objektam īpašu piekļuves politiku.

Java drošības modelis nosaka īpašu ierobežojumu drošības pārvaldniekam. Pirms Java 2 (iepriekš pazīstams kā JDK 1.2) lietojumprogramma sāka strādāt bez drošības pārvaldnieka (getSecurityManager () atgriezās nulle). Pirmais zvans uz setSecurityManager () izveidoja drošības pārvaldnieku, kuru pēc tam neļāva mainīt. Visi turpmākie zvani uz setSecurityManager () radītu drošības izņēmumu. Java 2 lietojumprogramma vienmēr tiek startēta ar drošības pārvaldnieku, taču līdzīgi kā iepriekšējās versijās setSecurityManager () metode ļaus jums mainīt drošības menedžeris ne vairāk kā vienu reizi.

Drošības pārvaldnieks sniedz labu piemēru tam, kā klases metodes var izmantot kopā ar privāto klases mainīgajiem, lai ieviestu īpašu piekļuves politiku objektiem, uz kuriem atsaucas klases mainīgie. Papildus lietderības metodēm domājiet par klases metodēm kā līdzekli, lai izveidotu īpašas piekļuves politikas objektu atsaucēm un klases mainīgajos saglabātajiem datiem.

Vadlīnijas

Galvenais šajā rakstā sniegtais padoms ir:

Neapstrādājiet klases kā priekšmetus.

Ja jums ir nepieciešams objekts, izveidojiet objektu. Ierobežojiet klases mainīgo un metožu lietošanu, definējot lietderības metodes un ieviešot īpašus piekļuves politikas objektus un primitīvos tipus, kas glabājas klases mainīgajos. Lai gan Java nav tīra uz objektu orientēta valoda, tomēr Java lielā mērā ir orientēta uz objektu, un tas jāatspoguļo jūsu dizainā. Domājiet par objektiem.

Nākammēnes

Nākamā mēneša Dizaina paņēmieni raksts būs pēdējais no šīs slejas. Drīz es sākšu rakstīt grāmatu, kuras pamatā ir Design Techniques materiāls, Elastīga Java, un, ejot, ievietos šo materiālu manā tīmekļa vietnē. Tāpēc, lūdzu, sekojiet tam projektam un sūtiet man atsauksmes. Pēc mēneša vai divu pārtraukuma es atgriezīšos plkst JavaWorld un Saules pasaule ar jaunu sleju, kas koncentrēta uz Jini.

Pieprasījums pēc lasītāja līdzdalības

Es aicinu jūsu komentārus, kritiku, ieteikumus, liesmas - visa veida atsauksmes - par šajā slejā sniegto materiālu. Ja kaut kam nepiekrītat vai jums ir ko pievienot, lūdzu, informējiet mani.

Jūs varat piedalīties diskusiju forumā, kas veltīts šim materiālam, ievadīt komentāru, izmantojot veidlapu raksta apakšdaļā, vai nosūtīt man e-pastu tieši, izmantojot saiti, kas sniegta manā biogrāfijā.

Bils Venners programmatūru profesionāli raksta 12 gadus. Atrodas Silīcija ielejā, viņš sniedz programmatūras konsultēšanas un apmācības pakalpojumus ar nosaukumu Artima Software Company. Gadu gaitā viņš ir izstrādājis programmatūru plaša patēriņa elektronikas, izglītības, pusvadītāju un dzīvības apdrošināšanas nozarēm. Viņš ir ieprogrammējis daudzās valodās uz daudzām platformām: montāžas valoda uz dažādiem mikroprocesoriem, C uz Unix, C ++ uz Windows, Java tīmeklī. Viņš ir grāmatas McGraw-Hill izdotās grāmatas Inside the Java Virtual Machine autors.
$config[zx-auto] not found$config[zx-overlay] not found