Отлично, пиши если нужна помощь или возникнут вопросы!
Не почтите за хамство, но местами вы строите лишние конструкции кода, вот к примеру:
public static bool IsVoid_e (this Tab tab, string xpath, int num = 0, bool b = false)
{
if (!tab.FindElementByXPath(xpath,0).IsVoid) b = true;
return b;
}
Зачем параметр по умолчанию, bool b = false ?
if (!tab.FindElementByXPath(xpath,0).IsVoid) b = true; // Нет, не пусто!
return false; // Пусто!
А еще не понятно, зачем в каждый метод дублировать текущий поток?
class Main
{
MyClass myClass;
public Main(Instance Instance, IZennoPosterProjectModel Project)
{
myClass = new MyClass(this);
}
}
class MyClass
{
void Method(Main currThread, param args)
{
// какая то реализация
}
void Method2(Main currThread, param args)
{
// какая то реализация
}
public MyClass(Main currThread)
{
// присвоить по умолчанию
}
}
Из статьи
Создавая таким образом архитектуру приложения, конечно. Мое мнение, Вы сделали, очень жестко зависимые классы, будто конкретный комбайн, а по сути нужен инструментарий (возможности которого легко модернизировать в процессе).
Инстранцируя главный объект, он знает обо всей архитектуре, то есть все сразу загружается в память, но при этом, половина всего из, ему возможно не нужна.
Пример аналогии:
Человек, Гардероб, Одежда в гардеробе (головной убор, верхняя одежда, штаны, обувь).
Задача:
Нужно одеть человека, чтобы он пошел гулять. Когда он ушел гулять, зачем ему помнить, что у него еще в гардеробе? Если только не переодеться, но это нужно возвращаться домой, лесть в гардероб и пр., но этим управляет программист.
Алгоритм:
То есть, инстанцировали человека, инстанцировали те предметы, необходимых вещей (кепка, кофта, штаны, куртка, ботинки), отправили человека, возможно по пути стало жарко, он снял куртку (убили экземпляр) и продолжает идти уже без куртки.
