J: Tātad, kam vispār ir noderīgas iekšējās klases?
A: Iekšējās klases ligzdo citās klasēs. Normāla klase ir tieša paketes, augstākā līmeņa klase. Iekšējām klasēm, kas kļuva pieejamas ar Java 1.1, ir četras garšas:
- Statiskās dalībnieku klases
- Dalībnieku klases
- Vietējās nodarbības
- Anonīmās nodarbības
Apskatīsim katru pēc kārtas ātri.
Īsāk sakot, a statiskā dalībnieku klase ir statisks klases loceklis. Tāpat kā jebkurai citai statiskai metodei, arī statiskai dalībnieku klasei ir piekļuve visām vecāku vai augstākā līmeņa klases statiskajām metodēm.
Tāpat kā statiskā dalībnieku klase, a dalībnieku klase tiek definēts arī kā klases loceklis. Atšķirībā no statiskās šķirnes, dalībnieku klase ir specifiska gadījumam, un tai ir piekļuve visām metodēm un dalībniekiem, pat vecāku šo atsauce.
Vietējais klases tiek deklarētas koda blokā un ir redzamas tikai šajā blokā, tāpat kā jebkurš cits metodes mainīgais.
Visbeidzot, an Anonīms klase ir vietējā klase, kurai nav nosaukuma.
Lai atbildētu uz jūsu konkrēto jautājumu, es koncentrēšos uz dalībniekiem un anonīmām iekšējām klasēm, jo tieši tās jūs varētu sastapt un izmantot. Man iekšējo klašu priekšrocības var iedalīt trīs kategorijās: objektorientētas priekšrocības, organizatoriskas priekšrocības un atzvanīšanas priekšrocības.
Objektorientētā priekšrocība
Pēc manas pazemīgās domām, vissvarīgākā iekšējās klases iezīme ir tā, ka tā ļauj lietas pārvērst par objektiem, kurus parasti nepārvērstu par priekšmetiem. Tas ļauj jūsu kodam būt vēl objektīvāk orientētam, nekā tas būtu bez iekšējām klasēm.
Apskatīsim dalībnieku klasi. Tā kā tā instance ir vecāku instances locekle, tai ir piekļuve visiem vecāku dalībniekiem un metodēm. No pirmā acu uzmetiena tas varētu nešķist daudz; mums jau ir šāda veida piekļuve no vecāku klases metodes. Tomēr dalībnieku klase ļauj mums izņemt loģiku no vecākiem un to objektīvizēt. Piemēram, koku klasē var būt metode un daudzas palīgmetodes, kas veic koku meklēšanu vai staigāšanu. No objektorientēta viedokļa koks ir koks, nevis meklēšanas algoritms. Tomēr, lai veiktu meklēšanu, jums ir nepieciešamas tuvas zināšanas par koka datu struktūrām.
Iekšējā klase ļauj mums noņemt šo loģiku un ievietot to savā klasē. Tātad no objektorientēta viedokļa mēs esam izņēmuši funkcionalitāti no vietas, kur tā nepieder, un esam to ievietojuši savā klasē. Izmantojot iekšējo klasi, mēs esam veiksmīgi atdalījuši meklēšanas algoritmu no koka. Tagad, lai mainītu meklēšanas algoritmu, mēs varam vienkārši nomainīt jaunu klasi. Es varētu turpināt, bet tas paver mūsu kodu daudzām priekšrocībām, ko sniedz objektorientētas metodes.
Organizatoriskā priekšrocība
Uz objektu orientēts dizains nav ikviena lieta, bet par laimi iekšējās klases nodrošina vairāk. No organizatoriskā viedokļa iekšējās klases ļauj mums tālāk organizēt paketes struktūru, izmantojot nosaukumvietas. Tā vietā, lai visu izmestu plakanā iepakojumā, klases var turpināt ligzdot klašu ietvaros. Nepārprotami, bez iekšējām klasēm mēs aprobežojāmies ar šādu hierarhijas struktūru:
pakete1 1. klase 2. klase ... n klase ... pakete n
Iekšējās klasēs mēs varam rīkoties šādi:
pakete 1 klase 1 klase 2 klase 1 klase 2 ... klase n
Rūpīgi lietojot, iekšējās klases var nodrošināt strukturālu hierarhiju, kas dabiskāk atbilst jūsu klasēm.
Atzvana priekšrocība
Iekšējo dalībnieku klases un anonīmās klases nodrošina ērtu metodi atzvanīšanas noteikšanai. Acīmredzamākais piemērs attiecas uz GUI kodu. Tomēr atzvanīšana var tikt piemērota daudziem domēniem.
Lielākajai daļai Java GUI ir sava veida komponents, kas rosina actionPerformed () metodes izsaukums. Diemžēl lielākajai daļai izstrādātāju vienkārši ir galvenā loga ieviešana ActionListener. Tā rezultātā visiem komponentiem ir vienāds actionPerformed () metodi. Lai noskaidrotu, kurš komponents veicis darbību, tajā parasti ir milzīgs, neglīts slēdzis actionPerformed () metodi.
Šeit ir monolīta ieviešanas piemērs:
publiskā klase SomeGUI paplašina JFrame īsteno ActionListener {aizsargātā JButton button1; aizsargāta JButton button2; ... aizsargāta JButton buttonN; public void actionPerformed (ActionEvent e) {if (e.getSource () == button1) {// dari kaut ko citu, ja (e.getSource () == button2) {... jūs iegūstat attēlu Ikreiz, kad redzat slēdžus vai lielus ja/ja vēl blokiem, prātā vajadzētu sākt skanēt trauksmes zvanu signāliem. Parasti šādas konstrukcijas ir slikts objektorientēts dizains, jo, mainot vienu koda sadaļu, var būt nepieciešamas attiecīgas izmaiņas komutatora paziņojumā. Iekšējo dalībnieku klases un anonīmās klases ļauj mums izvairīties no pārslēgtajiem actionPerformed () metodi.
Tā vietā mēs varam definēt iekšējo klasi, kas īsteno ActionListener katram komponentam, kuru mēs vēlamies klausīties. Tā rezultātā var rasties daudzas iekšējās klases. Tomēr mēs varam izvairīties no lieliem komutatoru paziņojumiem, un mums ir papildu bonuss, iekļaujot mūsu darbības loģiku. Turklāt šī pieeja var uzlabot veiktspēju. Slēdžā, kur tādi ir n salīdzinājumus, mēs varam sagaidīt n / 2 salīdzinājumi vidējā gadījumā. Iekšējās klases ļauj mums izveidot saraksti 1: 1 starp darbības veicēju un darbību klausītāju. Lielā GUI šāda optimizācija var būtiski ietekmēt veiktspēju. Anonīma pieeja var izskatīties šādi:
publiskā klase SomeGUI paplašina JFrame {... pogas dalībnieku deklarācijas ... aizsargāta void buildGUI () {button1 = new JButton (); button2 = new JButton (); ... button1.addActionListener (new java.awt.event.ActionListener () {public void actionPerformed (java.awt.event.ActionEvent e) {// darīt kaut ko}}); .. atkārtojiet katru pogu Izmantojot iekšējo dalībnieku klases, tā pati programma izskatās šādi:
publiskā klase SomeGUI paplašina JFrame {... pogas dalībnieku deklarācijas // iekšējās klases definīcijas klase Button1Handler īsteno ActionListener {public void actionPerformed (ActionEvent e) {// do something}} ... definējiet katras pogas aizsargāto void buildGUI iekšējo dalībnieku klasi () {// inicializēt pogas button1 = new JButton (); button2 = new JButton (); ... // reģistrē iekšējās klases darbību klausītāja instanci // katrai pogai button1.addActionListener (new Button1Handler ()); .. atkārtojiet katru pogu Tā kā iekšējām klasēm ir piekļuve visam, kas atrodas vecākos, mēs varam pārvietot jebkuru loģiku, kas būtu parādījusies monolītā actionPerformed () ieviešana iekšējai klasei.
Es labprātāk izmantoju dalībnieku klases kā atzvanīšanu. Tomēr tas ir personisko izvēļu jautājums. Es vienkārši jūtu, ka pārāk daudz anonīmo klašu pārblīvē kodu. Es arī uzskatu, ka anonīmās klases var kļūt apgrūtinošas, ja tās ir lielākas par vienu vai divām rindām.
Trūkumi?
Tāpat kā ar visu citu, jums ir jāņem labais ar slikto. Iekšējām klasēm ir savi trūkumi. No apkopes viedokļa nepieredzējušiem Java izstrādātājiem var būt grūti saprast iekšējo klasi. Iekšējo klašu izmantošana palielinās arī kopējo nodarbību skaitu jūsu kodā. Turklāt no attīstības viedokļa lielākā daļa Java rīku ir mazliet īsi par to, kā viņi atbalsta iekšējās klases. Piemēram, es ikdienas kodēšanai izmantoju IBM VisualAge Java. Kamēr iekšējās klases tiks apkopotas VisualAge, iekšējās klases pārlūkprogrammas vai veidnes nav. Tā vietā jums vienkārši jāieraksta iekšējā klase tieši klases definīcijā. Diemžēl tas apgrūtina iekšējās klases pārlūkošanu. Ir arī grūti rakstīt, jo, ierakstot klases definīciju vai izmantojot iekšējo klasi, jūs zaudējat daudzus VisualAge koda pabeigšanas palīglīdzekļus.
Tonijs Sintess ir ObjectWave vecākais konsultants, specializējies telekomunikāciju jomā. Sintes, Sun sertificēts Java 1.1 programmētājs un Java 2 izstrādātājs, ar Java strādā kopš 1997. gada.Uzziniet vairāk par šo tēmu
- Saules "Iekšējo klašu specifikācija" sniedz padziļinātu ieskatu iekšējās klasēs
//java.sun.com/products/jdk/1.1/docs/guide/innerclasses/spec/innerclasses.doc.html
Šo stāstu "Iekšējās klases" sākotnēji publicēja JavaWorld.
