Mfcttrf

Here is a shortest possible syntax for replacing whitespaces with null and throwing an exception where it is not allowed:

public class Name

 string _first;
 public string First
 
 get => _first;
 set => _first = (Optional)value;
 

 string _middle;
 public string Middle
 
 get => _middle;
 set => _middle = (Required)value;
 

Where:

public class Optional

 public static explicit operator Optional(string text) => new Optional(text);
 public static implicit operator string(Optional optional) => optional.Text;
 Optional(string text) => Text = IsNullOrWhiteSpace(text) ? null : text;
 string Text get; 

And:

public class Required

 public static explicit operator Required(string text) => new Required((Optional)text);
 public static implicit operator string(Required required) => required.Text;
 Required(string text) => Text = text ?? throw new FormatException();
 string Text get; 

P.S. Value modification on property assignment is not recommended, but could be very handy sometimes :)

Reasoning Update

@visualmelon I did it to have a chance to say the following: 😊

I do assume that OOD and a scalable language paradigm is the only way to keep high morale of the software development process. Seriously, the price of not knowing the default visibility of a class API member is tremendous. Damn, people, learn it and stop this ongoing customer robbery. This industry is ruined by cheap labor, the believe that everybody could code and that excessive usage of POCO could substitute basic understanding of the OOD principals, but it is wrong. One need a totally screwed economic environment to reason on this stuff positively. (My current project has 80% code redundancy! Start using ValueObjects, switch to Event Sourcing and all those left hand-right hand excessive assignments will be gone with the wind reducing the cost of support tremendously…)

Static functions vs custom types: static functions require extra “using static” directive while classes are not. And I do believe that it is totally OK to have a concept of Optional and Required string to be captured as classes in, let’s say, text processing domain. It could sound out of context somewhere else, but domain namespaces do matter… I would use different exception type, different names instead of Optional and Required in the different wider context, something like (NullIfWhitespace)text and (ThrowIfWhitespace)text.

P.S. Cracking software interviews book suggest to do not mention .NET experience while being interviewed for a non C# position. I am personally is just ashamed but understood the reason. We should be more open to gaining efficiency everywhere we could.

Not sure that adding a 7-line validator class per validation rule (plus typecasting abuse) is any shorter/better than a set of more straightforward composable validating one-liners, something like:

public static class ValidatingTransformers

 public static T ThrowsIfNull<T>(this T s, string msg = "") =>
 s != null ? s : throw new ArgumentException(msg);
 public static string ThrowsIfEmpty(this string s, string msg = "") =>
 !string.IsNullOrWhiteSpace(s) ? s : throw new ArgumentException(msg);

 public static string EmptyIfNull(this string s) => s ?? "";
 public static string NullIfEmpty(this string s) => !string.IsNullOrWhiteSpace(s) ? s : null;

 ... et cetera

Some other thoughts:

1. Replacing empty/whitespace strings with null does not look like a great idea to me. Because, well, the null and the NullReferenceException. An empty string looks like a safer alternative.


2. I'd avoid property setters and mutating a state, even if setters protect invariants. Much simpler, shorter, and safer alternative:

public class Name

 public string First get; 
 public string Middle get; 
 public string Last get; 

 public Name(string first, string middle, string last)
 
 First = first.NullIfEmpty();
 Middle = middle.ThrowsIfNull("middle name must not be null");
 Last = last.ThrowsIfEmpty("last name must not be empty");
 

Shorter code, one single place for all validations, never ever get an object in an inconsistent state, no issues with concurrent mutations.

Edit: the tone of this might seem a bit negative, so I'll add that this was a fun one to review in hopes of lightening the mood ;)

Miscellaneous thoughts:

• This is horrifying! Why did you do this?!




• You can just about get away with this for properties, but for method calls with required/optional fields, a FormatException will be inadequate (an ArgumentException telling the caller which argument went wrong is important), which rather limits the scope of this technique.




• Because the thing is type specific, you could give it a sensible name (e.g. OptionalString), make both conversions implicit, and use it as the field type. This would required even less syntax, and would be somewhat less opaque to the maintainer who has to live with this.




• These need documentation: it's not obvious that an Optional should convert "" to null: this is enough to put me off it completely.



• 
  

  You can get this 'low-char-count syntax by using a static using and providing these as static methods to a static class. The advantages would include:

  
  
  
  • It's not horrifying
  
  
  • It requires less code, because you don't have to build a whole type and its conversions for each sort of string
  
  
  • You can't misuse the types in ways you didn't intend, and they don't appear everywhere
  
  
  • You can throw the static methods at a delegate if you have need
  
  
  • It's not horrifying
  
  
  • People who don't hate themselves can use the fully qualified name
  
  
  • It won't incur an allocation every time you assign a value (though using structs would address this already)
  
  
  • You have greater freedom with the type of checks you can perform (e.g. multiple parameters)
  
  
  • It will be easier to document, because the API will be single method, not a type+stuff
  
  
  • It's not horrifying
  
  



• It's good that the conversion to the types is an explicit one, as this limits the scope for things going wrong with the intended usage.



• It would be nice if the Text members were explicitly private, so there was no question as to your intentions.


• I personally do not like the expression-bodied syntax for constructors, but that's probably just me.