Арсений Ефремов

Это невозможно в рамках C#, потому что тип string - неизменяемый тип. Каждая новая строка имеет свой собственный экземпляр string (такое же поведение имеют все ValueType).
Если хотите добиться иного поведения, нужно использовать System.Text.StringBuilder.
Например:

public class stateEnterWord
        {
            private StringBuilder word;
            public void init(StringBuilder input)
            {
                word = input;
            }
            public void startExecution()
            {
                word.Append(Console.ReadLine());
            }
        }
  static void Main(string[] args)
        {
            stateEnterWord obj = new stateEnterWord();
            StringBuilder Name = new StringBuilder();
            obj.init(Name);
            obj.startExecution();
            Console.WriteLine(Name.ToString());
        }

Однако, если честно, это нарушает принципы ООП.

Если у вас консольное приложение спроектировано правильно и умеет принимать параметры командной строки, то можно воспользоваться методами System.Diagnostics.Process.Start, передать параметры в новый процесс, перенаправить поток вывода и считать оттуда информацию.

Если же нет, и переписать консольную программу нет возможности (а спецификация требует использования именно
этой сборки), тогда можно воспользоваться System.Reflection.Assembly, подгрузить инстанс класса основной программы, вызвать метод Main (или любой другой) и передать список аргументов. Кстати, в данном случае очень неплохо может облегчить жизнь тип dynamic, так как многие вещи он сам умеет распознавать. У такого подхода много минусов, но он рабочий, если нужна динамическая подгрузка.

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

Вполне возможно. Смотрите:

static IEnumerable<TResult> Map<TIn, TResult>(this IEnumerable<TIn> seq, Func<TIn, TResult> mapper){
    foreach(TIn item in seq) yield return mapper(item);
}
enum Parity { Even, Odd }
static void Test(){
    List<int> numbers = new List<int> { 1, 2, 3, 4, 5, 6 };
    Func<int, Parity> parity = (num) => num % 2 == 0 ? Parity.Even : Parity.Odd ;
    foreach(var parity in numbers.Map(parity)) 
        Console.Write(parity.ToString() + ", ");
}

Это выведет на экран "Odd, Even, Odd, Even, Odd, Even, ".
Чем вам не функциональный подход? И LINQ здесь нет (разве что самодельный).

Можете воспользоваться фреймворком SlimDX.

В общем случае, задачи такого рода сводятся к, наоборот, доказательству существования алгоритма.
Есть несколько универсальных базовых методов доказательств: от противного, индукция, инвариант, и т.д.

Для решения такой задачи, вам нужно выделить несколько основных тезисов, касающихся вашей проблемы:
1. Исходные данные
2. Варианты возможных действий с ними
3. То, как изменяются данные в процессе
4. Что должно получиться на выходе
Основываясь на этом можно применить вышеуказанные методы, например, предположить, что такой алгоритм существует, или, например, составить шаги индукции и определить, для всех ли случаев выполняются условия. В таком контексте, ваши исходные условия - это аксиомы, они нерушимы и не требуют доказательств. На основе аксиом можно строить некоторые леммы - такие себе "частичные доказательства" - какие-то более сложные положения, которые выводятся из аксиом, и помогают позже в конечном доказательстве. Следует также помнить, что условие доказательства можно искусственно усилить, для того, чтобы легче было доказать всю вашу теорему.
Больше об этом можно послушать в лекциях от MIT.

Это принципы, касающиеся не столько процесса выполнения программы, сколько её дизайна. Все изменения в данном случае - процесс переписывания исходного кода программистом.
Архитектура приложения должна быть составлена таким образом, чтобы для некоторого изменения её функционала, расширения и т.д. достаточно было бы изменить код лишь в узком круге мест, а для добавления нового - вовсе ничего не меняя, включить новые элементы. На такую гибкость, лёгкость в сопровождении/тестировании, читабельность, и направлены принципы ООД, которые определяются вот уже несколько десятков лет.
Это очень обширная тема, требующая огромных знаний и опыта в сфере ООП. Лучше начинать с чего-то простого, и не лезть в тот же MVC без хотя бы базового понимания этих принципов.

Текст вопроса звучит так, как будто бы автор предлагает нам хорошую книгу без воды, лол.
Есть одна суперкнига по OpenGL, она обучает работе с оной технологией, но также достаточно глубоко рассматривает и графические принципы тоже.
А вот подборочка годных глубоких книг. Некоторые даже у меня есть, хотя я не геймдев.

Не существует перегрузки оператора "<<" для ostream такой, чтобы она принимала class tv в качестве параметра. Попробуй определить метод toString() в классе tv, который будет выводить на экран то, что тебе нужно.
К тому же, в классе tv у тебя не перегружен оператор "=", поэтому присваивание идёт поверхностное. Не помню, как там со статическими массивами, но, скорее всего, они просто начинают ссылаться на другую область памяти (то есть на строки в соседнем элементе). Следовательно, если у тебя не были инициализированы чем-то элементы старше count, то всё заполнится мусором.
Ещё один момент заключается в том, что массив на самом деле не сжимается, это ты двигаешь элементы справа налево, оставляя в конце один неиспользуемый. Обычно в таких случаях выделяют память под новый массив меньшего размера, а потом переносят всё в него, например.

Не нравится SQL - пользуйтесь NoSQL, например MongoDB. Там заодно и индексы поддерживаются и всякое такое. Можно организовать и дерево. А можно метрическое пространство по кастомным хешам строк. Это уж как захочется.

Метод List<TElement>.ForEach(Action<TElement>) принимает в качестве параметра делегат (то есть, по сути, указатель на функцию), который обрабатывает каждый элемент списка.
Запись такого вида:

var list = new List<int>() { 1, 2, 3 };
list.ForEach(element => { Console.Write(element * element + " "); } );

Выведет на экран следующее: 1 4 9

Этот кусок кода полностью эквивалентен такому:

void Method(){
   var list = new List<int>() { 1, 2, 3 };
   list.ForEach(Square);
}
void Square(int element){
   Console.Write(element*element + " ");
}

Таким образом, и в первом и во втором случае, переменная element является текущим обрабатываемым значением из списка.