You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There could be a number of improvements to the VEXBuilder I found while working with it for the new VEXController / Service for the API
Acceptance Criteria
Factory to create new clients
Current implementation is a switch statement, which worked for the short timeline. We can redevelop this to function similarly to the SerializerFactory
Example
Optional Key method
NVD and future databases may have a key option. All VEX generations statements should be able to handle key or no key cases to prevent if-else trees
And let the client handle the key. As a note: the API key should NOT be a field in the client. We want to limit storing the key as much as possible, so the scope should be restricted to the method
AddAll VEXStatements method
Utility in builders to prevent looping through statements to add them one at a time
if (!statements.isEmpty())
for (VEXStatementvs : statements)
vb.addVEXStatement(vs);
~80% Code Coverage
The text was updated successfully, but these errors were encountered:
Overview
There could be a number of improvements to the
VEXBuilder
I found while working with it for the new VEXController / Service for the APIAcceptance Criteria
Current implementation is a switch statement, which worked for the short timeline. We can redevelop this to function similarly to the
SerializerFactory
Example
This can help abstract the code and make it expandable for new clients
VEX
Builders constructorsCurrently the builders are static classes, but they could be made to be their own classes. Cases like this:
can be solved with constructors.
VEX
Builders FactoriesThis may be too much but we need a more expandable way to add new VEX standards. The current implementation is limiting
NVD and future databases may have a key option. All VEX generations statements should be able to handle key or no key cases to prevent if-else trees
A better solution would be:
And let the client handle the key. As a note: the API key should NOT be a field in the client. We want to limit storing the key as much as possible, so the scope should be restricted to the method
Utility in builders to prevent looping through statements to add them one at a time
The text was updated successfully, but these errors were encountered: