-
Notifications
You must be signed in to change notification settings - Fork 0
Design
[to be added]
The SOLID principles are design principles that ensures software to be maintainable, scalable, and flexible. The SOLID principles consist of five principles which assert various rules.
Single Responsibility Principle
The SRP states that classes should only have one reason to change, meaning they only have one responsibility. All classes in this program adhere to SRP by having no more than one responsibility.
Open/Closed Principle:
The OCP states that classes should be open for extension and closed for modification. The system adheres to the OCP by use of interfaces to specify system behavior which can be implemented to extend the system such as implementing a subtype of the MarkSchemeLoader interface to parse the submission mark scheme from a .json file without the need to modify existing code, thus being to extension and closed for modification.
Liskov Substitution Principle:
The LSP states that if B is a subclass of A, then B substituting for A should always maintain program correctness, ensuring that subclasses of a superclass can still act correctly as the superclass. This relationship is present throughout the system in every realization and inheritance and can be seen in the fact that any subclass of GradeTemplate can work in the place of a GradeTemplate object while ensuring program correctness.
Interface Segregation Principle:
The ISP states that interfaces should not force subtypes to implement unused methods. In this system, no subtype is forced to implement methods that it does not use, meaning that the ISP is upheld.
Dependency Inversion Principle:
The DIP states that low level modules should not depend on high level modules but rather they should both depend on abstractions. In the system all modules depend on interfaces which acts as the abstraction between module levels. The DIP additionally states that abstractions should not depend on details but details should depend on abstractions. The system interfaces are written to declare behavior required for the system to function properly, which realizations must implement meaning that DIP is upheld.