Толстый Лорри

Я бы посоветовал:

• Не делать главный класс окна божественным объектом. Его нужно разделить на контролы-модули с их собственной кастомной логикой, валидацией и прочим, а связать между собой - сигналами и слотами.
  
• Отделять бизнес-логику от интерфейса. Для чего использовать внедрение зависимостей и абстрактные (чисто виртуальные) классы для декларирования API.
  

Допустим, парсером парсится конфиг в объект настроек, эти настройки передаются в фабрику, которая с оглядкой на них будет выдавать правильно сконфигурированные объекты по запросу. Ссылка на фабрику передается в класс окна, откуда добываются зависимости и передаются дальше контролам по ссылке. Контролы, получая зависимость (допустим, через конструктор), привязываются к ней через сигналы/слоты или непосредственно вызывают виртуальные методы.

Итог: интерфейс декомпозирован, о бизнес-логике он не знает ничего, кроме предоставленного абстрактного API. Контролы знают друг о друге только в рамках сигналов/слотов между собой и списка зависимостей своих детей. Бизнес-логика не знает ничего об интерфейсе.

Не стоит использовать ArrayListбез весомой на то необходимости. Поэтому компилятор не смог вас предупредить, что ArrayListсостоит из ArrayList'ов, в котором строки (двумерный массив строк), а не просто строк.

Вместо ArrayListнеобходимо использовать типизированный динамический массивList<string>.

public void Click_OpenFile()
{
    string fileName = form1.OpenFie();

    IList<string[]> aL = ParseFile(fileName);

    foreach (var line in aL)
    {
        // Снова собираем токены в строки
        MessageBox.Show(string.Join(" ", line));
    }
}

// Читаем файл и построчно парсим его
private IList<string[]> ParseFile(string fileName)
{
    if (string.IsNullOrEmpty(fileName))
    {
        throw new ArgumentNullException(nameof(fileName));
    }
    if (!File.Exists(fileName))
    {
        throw new ArgumentException($"There is no file {fileName}!");
    }

    string[] fileContent = File.ReadAllLines(result);
    var aL = new List<string[]>(fileContent.Length);
    foreach (var line in fileContent)
    {
        aL.Add(ParseString(line));
    }
    return aL;
}

// Разбиваем строки на токены
private string[] ParseString(string s)
{
    const char delimiter = '|';
    return s.Split(delimiter);
}

Потому что в будущем вы сможете безболезненно добавить логику в метод (получение значения из конфига, из базы, вызов проверки авторизации и т.п., для сеттера - валидация данных). Если же у вас будет голое поле, то придется изменять клиентский код, а это нарушает абстракцию.

Правило хорошего тона: API класса должен быть доступен только через методы или properties (что, по сути - синтаксический сахар над методами), а поля должны быть только private/protected.

var Human = (function (person) {

    this.firstName = "John";
    this.lastName = "Doe";
    this.age = person.age || 50;
    this.eyeColor = person.eyeColor || "blue";

    this.toString = function() {
        return person.age + ", " + person.eyeColor;
    };
});

var pers = new Human({ eyeColor: "Yellow" });
// 

console.log(pers);

Выглядеть в конечном итоге это может как-то так:

var SampleClass = (function(localFirstDependencyName, localSecondDependencyName){
    'use strict';
    
    var _defaultSettings = {
        option: 'option'
    }

    var constructor = function(settings){
        this._settings = $.extend(this._settings || {}, _defaultSettings, settings);
    
        this.publicField = null;
        this._protectedField = null;    
        this._privateField = null;
    };
        
    $.extend(constructor.prototype, {
        publicConstant: 'Constant',
        protectedConstant: 'Constant',
        _privateConstant: 'Constant',

        //#region Public
        publicMethod: function () {      
            this._protectedMethod();    
        },
        //#endregion
        
        //#region Protected
        _protectedMethod: function () {         
        },
        //#endregion

        //#region Private
        _privateMethod: function(self, value){
        },  
        //#endregion
    });
        
    return constructor;
}(globalFirstDependencyName, globalSecondDependencyName));

ИМХО, расточительно делать отдельную таблицу под пол. Отлично подойдет (если не уходить в дебри человеческих отклонений):

enum Sex { 
    Male,
    Female,
    Undefined
}

bool? - тоже вариант, но читается хуже.