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>