C# strongly typed properties

Question

I posted a question but need it clarified. I'm a beginner.

I'm not sure what the use of the term "strongly typed properties" means in this context? The syntax offered by the responder to my original post is what I'm after, but when I web search for this term, it only offers a definition and examples, not useful examples on how it's implemented in user defined classes.

Wouldn't this be best served with strongly typed properties, like h.Segments["PID"].Fields[5].Subfields[3].SubSubFields[2]? – Lasse Vågsæther Karlsen Aug 19 at 7:25

Overall, my aim is to

1. parse in a text file with many messages
2. loop through each message text (FS delimeted) and from that text create single message objects. Each of these messages have...
3. one or many message segments which have
4. one or many fields which have
5. zero or many subfields which have
6. zero or many sub-subfields

I'd ideally like to create and object like

HL7Message h = new HL7Message;

string name = h.segment[2].field[5].subfield[0];

How can I create and access an object whose properties have properties themselves?

Answer 1

You are really over-thinking this. Strongly typed only means (in this context), that you have classes that express themselves explicitly. This is really just ground level object oriented programming.

Ie Segment is a class, Field is a class, which have properties to simple types and also other strongly typed classes, etc.

If you need more information in segments, just add more properties etc. to it.

Given

public class HL7Message
{
   public List<Segment> Segments { get; set; }
}

public class Segment
{
   public string Name { get; set; }
   public List<Field> Fields { get; set; }
}

public class Field
{
   public string Name { get; set; }
   public List<Field> Fields { get; set; }
}

Setup

var message = new HL7Message()
        {
           Segments = new List<Segment>()
                {
                   new Segment()
                   {
                      Name = "PID",
                      Fields = new List<Field>()
                         {
                            new Field()
                            {
                               Name = "SomeField",
                               Fields = new List<Field>()
                                  {
                                     new Field()
                                     {
                                        Name = "SomeSubField",
                                        Fields = new List<Field>()
                                           {
                                              new Field()
                                              {
                                                 Name = "SomeSubSubField",
                                              }
                                           }
                                     }
                                  }
                            }
                         }
                   }
                }
        };

Usage

var someResult = message.Segments[1].Fields[1].Fields[1];

_{Note : This is not trying to build your application, merely just address the confusion you have been having over many questions.}

Answer 2

Another possible and slightly cleaner approach to this might be simplifying it to a self-referential class or node model (i.e. XML or the same Field class @TheGeneral has in their example) where you could have sub-sub-sub-sub-sub...fields if you wanted to. Every node then is identical (i.e. predictable) with the same level of feature support.

Note: The constructor in the below class ensures the Children property is always initialized so as to avoid handling nulls.

using System;
using System.Collections.Generic;

public class HL7Node
{
    public IDictionary<string, object> Fields {get; set; }
    public List<HL7Node> Children { get; set; }

    public HL7Node() 
    {
        Children = new List<HL7Node>();
    }
}

Example usage (see also https://dotnetfiddle.net/EAh9iu):

var root = new HL7Node {
  Fields = new Dictionary<string, object> {
    { "fname", "John" },
    { "lname", "Doe" },
    { "email", "jdoe@example.com" },
  },
};

var child = new HL7Node {
  Fields = new Dictionary<string, object> {
    { "fname", "Bob" },
    { "lname", "Doe" },
    { "email", "bdoe@example.com" },
  },
};

var grandChild = new HL7Node {
  Fields = new Dictionary<string, object> {
    { "fname", "Sally" },
    { "lname", "Doe" },
    { "email", "sdoe@example.com" },
  },
};

var greatGrandChild = new HL7Node {
  Fields = new Dictionary<string, object> {
    { "fname", "Ray" },
    { "lname", "Doe" },
    { "email", "rdoe@example.com" },
  },
};

root.Children.Add(child);
root.Children[0].Children.Add(grandChild);
root.Children[0].Children[0].Children.Add(greatGrandChild);

var message = string.Format("Grandchild's name is {0}", root.Children[0].Children[0].Fields["fname"]);

I don't know what your naming conventions requirements are for HL7 message exchange, but perhaps there's some opportunity to still execute those with serialization decorators (i.e. Newtonsoft.Json.JsonPropertyAttribute), anonymous objects, etc.