Interface PatternContract

Patterns represent software Design Patterns, which are used to solve complex problems in a scalable way through a uniform approach. This contract does not enforce requirements, but does designate that an implementing class is capable of fielding such behavior. There are also contracts for specific subsets of design patterns, which are pre-categorized to their typical scope. This family of contracts may be easily extended upon to add your own custom categorization. This package distributes the four most common categories out of the box: (behavioral, creational, structural, and concurrency), and provides generic implementations of most design patterns that will fit the majority of use cases. These are by far not the only solutions, and should not be taken to be mandatory answers in any regard.

The Contract Interfaces in this system that designate categories of patterns DO NOT enforce methods, and should be used only for categorization. The specific patterns DO enforce methods, which correspond to our released traits to honor them. If you want to fully develop your own that has no inherent correlation to our approach, you should IMPLEMENT THE CATEGORICAL CONTRACT, and NOT THE PATTERN SPECIFIC CONTRACT, then fill in the blanks as needed. Given the broad application of design patterns and huge variance of scope, we CAN NOT apply an enforced standard approach to them without enforcing opinion that reduces options

in various cases, which is against the mission of this software.

Contract interfaces enforce expected behavior in a non-colliding way. They are tasked with enforcing methods, and extending interfaces provided by standards and other packages for compatibility.

All valid oroboros classes MUST extend at

least one Contract Interface to be considered valid.