MAT

Je hebt een aantal imagecodes gecontroleerd, dat is oké.
Wanneer er nu een nieuwe MatKleur (of materiaal) bijkomt, dan zal deze test niet beginnen te falen. Logisch!
Als we zoiets wel willen, dan moeten we daarvoor een "SmokeTest" schrijven. Ik heb effe nagedacht, maar dat zou niet zo simpel zijn (gezien de combinatie van Materiaal en Kleur). Dus ik stel voor om het zo te laten, tenzij je zelf een briljant idee hebt.

Commentaar opkuisen :-P

... geeft lege AfbeeldingCode."

Ter informatie (om misverstanden in de toekomst te vermijden) :
Bij materiaal bestaat "antislip" en "antislip-Fiber"

Voor deze testmethods (naam) maakt het echt ni uit (dus ge hoeft het ni per sé aan te passen) maar let wel op als ge met andere mensen spreekt over "Antislip" terwijl ge "AntislipFiber" zou bedoelen.

$$$Implementation( MATImageCodeBepaler (i.p.v. "SST...")

en ook :
in nieuwe code gebruiken we $$$Inject i.p.v. $$$implementation

FormalSpec is copy-paste van LBX --> aanpassen naar MATImageCodeBepaler

copy-paste typo (2x) :
#dim ... As MVX-kenmerken ??

copy-paste 2x zelfde

copy-paste 2x zelfde

Mijn eerste review-opmerking ging zijn : "In een AssertEquals-expressie zou geen $Select() mogen staan."
Dat topic wil ik eventueel nog met jou bespreken.

Door dit op te merken, viel m'n oog wel op een typo in bovenstaande lijn: RugBreedteX en in de $Select() staat BreedteM :-O

Bij voorkeur Z1 en Z2 verschillend kiezen.
idem voor X en Y

Uitsparing Breedte.M moet je verplaatsen naar Dubbele uitsparing.

Deze IF legt een onnodige dependency, en heeft geen meerwaarde binnen de converter.
Integendeel, bij uitbreiding voor LBX sifon of TBX sifon moet je hier iets toevoegen, terwijl de code binnen de IF toch "universeel" is.

Ook de MatKenmerken hebben property "NietMeeleveren", dus ik zou deze method wel laten oproepen, ook al is de impl dan enkel met de eerste en de laatste lijn : %New() en Quit.
Oftewel rechtstreeks in de method Converteer() , dan mag de commentaar hier volledig weg.

VH code conventions : VulAanMatKenmerken()

Als het object MatKenmerken één en dezelfde oref blijft (dus geen %Clone ofzo) dan is het niet nodig om de SetAt() te doen, want de pointer in de GekoppeldeKenmerken verwjist nog steeds naar hetzelfde object in memory.

Een kleine bedenking:
ik ben niet helemaal zeker of de method wel thuishoort in deze klasse, omdat die enkel geschikt is voor MatKenmerken.

Voorlopig is dit oké, en functioneel zeker geen probleem.
Ik wil niet verder uitweiden nu, over deze bedenking, dus enkel als review-opmerking, en om te vermijden dat we vanalles in deze klasse gaan steken dat niet voor alle IngegevenKenmerken van toepassing is.

Er is geen IF nodig, want :
if "true" or "false" --> altijd dus
:-P

toegevoegde parameter "IsBerekendViaDotNet" ook doorgeven via ##super()