Metaclass ( engelsk Metaclass ) - i objektorienteret programmering er en klasse , hvoraf forekomster igen er klasser [1] [2] .
Ikke alle objektorienterede programmeringssprog understøtter metaklasser. De, der understøtter, implementerer en anden tilgang med deres egen protokol, oprettelse og håndteringsregler [3] .
Blandt de sprog, der understøtter metaklasser, er:
Derudover er der en række højt specialiserede, især såkaldte "akademiske" programmeringssprog, der understøtter og udforsker begrebet metaklasser [4] .
Java skiller sig ud , hvor der også er en enkelt metaklasse - Class (beskriver klasser), som er placeret i java.lang-biblioteket. Java giver dog ikke et udviklet koncept til at arbejde med metaklasser.
Metaklasser kan eksistere ikke kun som en enhed af et programmeringssprog, men også som en enhed af en flersproget platform. Metaklasser er mest eksplicit udtrykt i IBM System Object Model . Arkitekterne bag SOM tog højde for de positive aspekter af CLOS og løste en af dens mangler, inkompatibiliteten af metaklasser, på en måde, der var unik på det tidspunkt. En metaklasse-inkompatibilitet er en situation, hvor metaklassen af en underklasse ikke er en underklasse af metaklassen. I CLOS forårsager dette et nedbrud. Der kan opstå en situation, når forskellige dele af systemet udvikles af forskellige teams, og klassestrukturen i en del af systemet er ændret, mens disse ændringer i en anden del af systemet ikke er synkroniseret. Et af målene med SOM var at give maksimal binær kompatibilitet mellem udgivelser. En innovativ løsning introduceret i SOM 2.0 er oprettelsen af en anonym underklasse af flere metaklasser i tilfælde af, at ingen af metaklasserne i en klasse underklasser de andre. I CLOS og SOM 1.0 er det et krav at angive en metaklasse. I SOM 2.0 er det valgfrit at angive en metaklasse, og en faktisk metaklasse kan oprettes under kørsel, som arves fra flere forældre: den ønskede metaklasse såvel som metaklasserne for hver superklasse.
Eksplicitte metaklasser er specificeret, når en klasse erklæres. En udvikler, der har evnen til eksplicit at specificere en metaklasse, kan skabe vilkårligt komplekse hierarkier.
Hvis objektmodellen kun understøtter implicitte metaklasser, betyder det, at der syntaktisk kun er et klassehierarki, men der er såkaldte klassemetoder i klasserne. I dette tilfælde afspejler metaklassehierarkiet klassehierarkiet. Almindelige metoder føjes til en almindelig klasse, og klassemetoder føjes til den tilsvarende metaklasse, men udvikleren kan ikke etablere vilkårlige arveforhold mellem metaklasser og klasser. Klassemetoder kan være rigtige metoder, eller de kan være "syntaktisk sukker", det vil sige, de er synlige, hvis du tilgår klassen ved navn, men er ikke synlige, hvis du forsøger at kalde dem som almindelige metoder på en variabel, der tidligere blev tildelt en henvisning til samme klasse.
En kæde af klasser af klasser af klasser ... opfører sig forskelligt i forskellige objektmodeller.
I modeller med implicitte metaklasser understøttes spejling af hierarkier og derfor separation. Så i Delphi kan metaklasser ikke have deres eget navn, men identificeres altid som "klasse af ...", og da "klasse af klasse af ..." er en syntaktisk forkert konstruktion, ender kæden på metaklassen. I SmallTalk og Objective-C er klasser, selvom de er implicitte, stadig objekter ligesom almindelige, så det er umuligt at bryde kæden.
I modeller med eksplicitte metaklasser er klasser objekter, så det er også umuligt at bryde kæden. Hvis kæden ikke er brudt, skal der enten være en speciel basisklasse, designet til at være en klasse for sig selv, eller også er denne kæde potentielt uendelig med oprettelsen af successive metaklasser i farten.
En metaklasse-inkompatibilitet er en situation, hvor metaklassen af en underklasse ikke er en underklasse af metaklassen. Det vil sige, at der kan være en eller anden kode, der fungerer med forekomster af klasse A, om hvilken det er kendt, at dens klasse (metaklassen for dens forekomster) er klassen MA, og klassemetoder fra MA kan kaldes på ethvert objekt af klasse A . Så, hvis det pludselig er muligt at oprette forekomster af efterkommere af klasse A, der ikke understøtter klassemetoder fra MA, vil sådanne forekomster af efterkommere være inkompatible med kode, der forventer forekomster af A, hvilket er i modstrid med principperne i OOP. For at forhindre sådanne latente fejl i at opstå, er oprettelsen af sådanne børn normalt blokeret.
I modeller med implicitte metaklasser, på grund af spejling af hierarkier, er denne situation i princippet udelukket. I modeller med eksplicitte metaklasser kan du enten crashe programmet eller konstruere en metaklasse, der er et barn af hver basisklasses metaklasse og den ønskede klasses metaklasse. Dette kræver naturligvis støtte til multipel arv.
| Objektmodel | C++ | Delphi | Java og .NET | SmallTalk og Objective-C | rubin | LUKKET | Python | SOM og PMtW [5] |
|---|---|---|---|---|---|---|---|---|
| Eksplicitte metaklasser? | RTTI | implicit | implicit | implicit | ? | eksplicit | eksplicit | eksplicit |
| Er en klasse et almindeligt objekt? | Ingen | Ingen | Ja | Ja | ? | Ja | Ja | Ja |
| Er klassemetoder klassemetoder? | Ingen | Ja | Ingen | Ja | Ja | Ja | Ja | Ja |
| En kæde af klasser af klasser af klasser ... | bryder af | bryder af | besat | besat | endeløs | besat | besat | besat |
| Hvis underklassens metaklasse ikke er en underklasse af metaklassen, så | n/a | n/a | n/a | n/a | ? | fejl | fejl | den ønskede er designet |