<commit_before># Architektur eonum search frontend

![](architecture.png)

Die eonum-API kennt drei verschiedene Kataloge. Diese Kataloge weisen zahlreiche Gemeinsamkeiten auf, welche teilweise in eine Oberklasse `Catalog` ausgelagert werden können.

Da jeder Katalog jedoch auch einige Besonderheiten (insbesondere eine andere Objekt-Hierarchie) besitzt, wird jeder Katalog durch eine eigene Klasse modelliert (`SwissDrgCatalog`, `ChopCatalog` und `IcdCatalog`). Katalog-spezifisches Verhalten kann damit gekapselt werden.

Die Kataloge kommunizieren jedoch nicht direkt mit der eonum-API, da dies die Testbarkeit der Kataloge beeinträchtigen würde. Die eonum API wird von Services abgefragt. Jeder Service kapselt dabei die Funktionalität der API für einen spezifischen Katalog. `ISwissDrgService` kapselt den SwissDRG-spezifischen Teil der API, analog für `IChopService` und `IIcdsService`. Unter Umständen können einige Gemeinsamkeiten in einer Service-Oberklasse ausgelagert werden.

Zum Testen können beliebige Fake-Objekte, welche das jeweilige Service-Interface implementieren, im Konstruktor an den Katalog übergeben werden (Dependency Injection).

Die jeweiligen Objekte der Kataloge werden alle mit konkreten Klassen und einer entsprechenden Parent-Child-Hierarchie abgebildet. Gemeinsamkeiten können unter Umständen in eine abstrakte Oberklasse `CatalogElement` ausgelagert werden.<commit_msg>Use relative path for image in architecture document.<commit_after># Architektur eonum search frontend

![](./Architecture.png)

Die eonum-API kennt drei verschiedene Kataloge. Diese Kataloge weisen zahlreiche Gemeinsamkeiten auf, welche teilweise in eine Oberklasse `Catalog` ausgelagert werden können.

Da jeder Katalog jedoch auch einige Besonderheiten (insbesondere eine andere Objekt-Hierarchie) besitzt, wird jeder Katalog durch eine eigene Klasse modelliert (`SwissDrgCatalog`, `ChopCatalog` und `IcdCatalog`). Katalog-spezifisches Verhalten kann damit gekapselt werden.

Die Kataloge kommunizieren jedoch nicht direkt mit der eonum-API, da dies die Testbarkeit der Kataloge beeinträchtigen würde. Die eonum API wird von Services abgefragt. Jeder Service kapselt dabei die Funktionalität der API für einen spezifischen Katalog. `ISwissDrgService` kapselt den SwissDRG-spezifischen Teil der API, analog für `IChopService` und `IIcdsService`. Unter Umständen können einige Gemeinsamkeiten in einer Service-Oberklasse ausgelagert werden.

Zum Testen können beliebige Fake-Objekte, welche das jeweilige Service-Interface implementieren, im Konstruktor an den Katalog übergeben werden (Dependency Injection).

Die jeweiligen Objekte der Kataloge werden alle mit konkreten Klassen und einer entsprechenden Parent-Child-Hierarchie abgebildet. Gemeinsamkeiten können unter Umständen in eine abstrakte Oberklasse `CatalogElement` ausgelagert werden.
{'fraction_non_alphanumeric': 0.0438288920056101, 'fraction_numerical': 0.0, 'mean_word_length': 6.372093023255814, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '97238', 'n_tokens_mistral': 854, 'n_tokens_neox': 923, 'n_words': 326}