For instance we have function which get 2 numbers and return sum of them. The first number is odd and the second is even.
functionoddEvenSumm(odd,even){if(even%2==1){thrownewError('not even one')}if(odd%2==0){thrownewError('not odd one')}returnodd+even;}
Should we create new types for these values (like you did for title and body) because we validate them?
Do we break Single Responsobiliy Principal?
Does it make sence to create separate type if we don't use them in other places?
Opaque types allow to capture guarantees and propagate them. If you only need these guarantees on a specific part of your code and there is no need to propagate them, then it is probably not worth it to create opaque types for them. In other words, not every "validation check" should result in an opaque type.
However, most of the time this is an API design choice. For instance, I would understand this API better than the example you provided:
For instance we have function which get 2 numbers and return sum of them. The first number is odd and the second is even.
Should we create new types for these values (like you did for title and body) because we validate them?
Do we break Single Responsobiliy Principal?
Does it make sence to create separate type if we don't use them in other places?
Opaque types allow to capture guarantees and propagate them. If you only need these guarantees on a specific part of your code and there is no need to propagate them, then it is probably not worth it to create opaque types for them. In other words, not every "validation check" should result in an opaque type.
However, most of the time this is an API design choice. For instance, I would understand this API better than the example you provided:
The advantages here are:
sum
error-free! We can call it multiple times without having to deal with errors:sum (sum odd even) even
sum
value is guaranteed to be anOdd
number.