L'API publique à été concue pour offrir un maximum de fonctionnalités aux utilisateurs sans compromettre la flexibilité d'implémentation. La seule classe offrant une implémentation concrète étant la CatalogFactory chargée d'instancier les bonnes sous-classes en fonction du type de catalogue.
Si plus d'options de stockage venaient à se présenter (ex. JSON), un refactor de la factory serait très probablement nécéssaire afin de mieux supporter des implémentations arbitraires.
La première partie de l'API est une copie conforme du modèle de domaine en termes d'implémentation. Elle fournit un moyen de parcourir et modifier les données du catalogue de manière simple.
<uml> hide empty methods hide empty fields
class CatalogFactory «Singleton» {
+ load(url, config?): Catalog + create(url, config?): Catalog
} CatalogFactory ..> Catalog : creates
abstract class VolumeStore {
+ getVolume(metadata, type) + addVolume(metadata, volume) + deleteVolume(metadata) + editVolume(metadata)
} VolumeStore ..> Volume : loads VolumeStore <.. VolumeMetadata
abstract class Catalog {
+ isRemote(): bool + isLocal(): bool
} Catalog –> Category : root
interface CatalogNode {
+ name
} Catalog ← CatalogNode : catalog CatalogNode - VolumeMetadata
CatalogNode <|– Category interface Category { } CatalogNode “*” – “1” Category
CatalogNode <|– Series interface Series { } Series → SeriesMetadata : metadata
interface VolumeMetadata {
+ number + title
} VolumeMetadata ← Volume VolumeMetadata –> “0..1” SeriesMetadata
interface SeriesMetadata {
+ authors[*] + artists[*] + released + summary
} SeriesMetadata –> Tag : tags
interface Tag {
+ name
}
interface Volume { } Volume –> “*” Page
interface Page {
+ contents
}
</uml>
La seconde partie de l'API permet d'interragir avec les différents éléments de stockage liés aux données d'un catalogue.
CatalogConfig configure les chemins du cache du catalogue. Les différents chemins fournis par cette classe sont passés aux autres composants.INodeFactory permet de créer des classes correspondant au moteur de stockage du catalogue.ICatalogWriter permet de sauvegarder le catalogue en utilisant son moteur de stockage.VolumeStore gère le chargement, sauvegarde, ajout, import et supression de volumes dans le système de fichiers. Cetaines de ces opérations peuvent être indisponnibles selon l'emplacement du catalogue.ThumbnailStore permet de récupérer la miniature associée à un volume. Selon l'implémentation elle sera soit extraite du fichier cbz ou téléchargée et mise en cache.<uml> hide empty methods hide empty fields
class CatalogFactory «Singleton» {
+ load(url, config?): Catalog + create(url, config?): Catalog
} CatalogFactory ..> Catalog : creates CatalogFactory –> CatalogConfig : defaultConfig
class CatalogConfig {
+ cachePath
}
abstract class Catalog {
+ isRemote(): bool + isLocal(): bool
} Catalog → CatalogConfig : config Catalog –> INodeFactory Catalog –> ICatalogWriter Catalog –> VolumeStore Catalog –> ThumbnailStore
interface INodeFactory {
+ createCategory(name): Category + createSeries(name): Series + createVolume(number, name?): VolumeMetadata + createSeriesMetadata(): SeriesMetadata + createTag(): Tag
}
interface ICatalogWriter {
+ write() + writeTo()
}
interface Volume { }
class VolumeFactory «Singleton» {
+ getLoader(type): IVolumeLoader + getWriter(): IVolumeWriter
}
VolumeFactory ..> IVolumeLoader : creates VolumeFactory ..> IVolumeWriter : creates
interface IVolumeLoader {
+ load(path, metadata): Volume
} IVolumeLoader ..> Volume : loads
interface IVolumeWriter {
+ load(path): Volume + createEmpty(): Volume + write(path, volume) + createPage(volume): Page + setPageName(page) + setPageContents(page)
}
abstract class VolumeStore {
+ getVolume(metadata, type): Future<Volume> + addVolume(metadata, volume) + deleteVolume(metadata) + editVolume(metadata): Future<Volume>
} VolumeStore …> IVolumeLoader : uses
abstract class ThumbnailStore {
+ getThumbnail(metadata): Future<byte[]>
} </uml>