Tak for dit svar.
Soren Kuula wrote:
> Du kender godt getRoots, eller hvad den lige hedder, på File, ikke?
Jo. File er adgang på filsystem-niveau. Med mit API er det et lavere
niveau man har i tankerne. Følgende skal gerne kunne lade sig gøre,
når jeg færdig:
1) Liste partitioner og typer af filsystem - og om disken overhovedet
understøtter partitioner.
2) Læse MBR/PBR eller skrive, dvs. skifte koden ud i dem.
3) Læse og skrive til "hidden sectors", hvis de findes.
4) Angive en fil og få dens fysiske position på disken, samt om den
er fragmenteret - og i så fald skal man kunne defragmentere lige netop
den fil.
5) Sætte en fil til at være systemfil, dvs. den ikke bliver flyttet
eller skrevet til uden videre.
6) Få et File-objekt der repræsenterer roden af en partition
Selv vil jeg bruge API'et til at lave nogle værktøjer, FStools kalder
jeg dem, og BootConfig. Det sidste skal kunne installere en ny
bootloader/bootmanager på din computer - og hente opdateringer til
den, hvis der er.
Ad punkt 4) og 5) bliver det lidt svært, for det har jeg jo på sin
vis noget med et filsystem at gøre, hvor alle andre metoder ikke har
noget med selve filsystemet (eller filerne) at gøre. Men jeg har
tænkt at man måske kan give et File-objekt som parameter til de filer
man ønsker at operere på. Eller bruge adapter pattern i en
LowlevelFile klasse, der modtager et File-objekt i constructoren.
> Jo det er vist en alm. løsning:
>
> interface Drive {
> ...
> }
>
> interface Drives extends Iterable<Drive> {
> ...
> }
>
> class FileSystems {
> static DriveAccessorDims getBootstrap() {...}
> }
>
> -- der er jo ikke nogen som tvinger dig til at skrive FileSystems som en
> impl. af Drives. Der er heller ikke nogen der tvinger dig dit ikke at
> gøre det.
Ah, point taken. Jeg kan jo ikke vide at de vil implementere det hele -
eller på samme måde - det er op til dem. I så fald må det ikke
være min opgave at fortælle hvordan implementationen bruges. Jeg kan
jo godt beskrive en måde jeg har forestilt mig det implementeret på -
men ellers er det helt op til brugeren af en implementation at finde ud
af hvordan den virker.
Men det jeg ellers havde i tanken: interoperabilitet. Hvis en
applikation er skrevet til at bruge xx.yy.drives.implementation.Drives
i deres applikation - og den implementation kun findes til Windows og
Linux, f.eks. Hvad så når de vil køre den på Mac? Så finder de en
implementation til Mac, men den er placeret i aa.bb.cc.Drives i stedet
- så skal de til at rette hele deres applikation igennem. Det var
egentlig det jeg var ude efter ikke skete.
> .. det bedste praktiske design kommer sjældent ved at jappe det sammen
> helt uden at tænke sig om ... men heller ikke ved at tænke alt igennem
> til perfektion (det ender tit med noget som ser smart ud, bare fordi det
> ikke er set før, men i virkeligheden er kluntet & forvirrende). Men hvis
> man tænker sig lidt om fra starten, gætter hvad der er væsentligst, og
> så retter til efterhånden (refactoring tools er godt) som de reelle
> betingelser og alle forglemmelserne viser sig, så kører det...
Point taken - igen
Det kører det her.
> En abstrakt klasse kan forresten kun en ting ekstra: Erklære en
> ikkestatisk metode (eller _få_ den erklæret ved at implementere et
> interface hhv extende in abstrakt klasse), men undlade at implementere
> den. Og du kan altid lave en klasse abstrakt -- men må så ikke
> instantiere den.
Ja, det er korrekt. Men jeg har indset at jeg brugte min abstrakte
klasse helt forkert. Jeg lavede den abstrakt, fordi den så fungerede
som et interface, samtidig med at jeg kunne placerere en statisk metode
i den. Det har jeg droppet nu - i stedet laver jeg rene interfaces. Det
giver jo faktisk også mere overskuelighed.
Det kan dog være jeg laver nogle AbstractXX klasser som implementerer
nogle af de meget generelle metoder i interfacet XX - som en hjælp til
dem der laver en implementation.
Mvh.
Bjarke W.