Станислав Макаров

Попробуйте UTF-16:
windows-installer-xml-wix-toolset.687559.n2.nabble...

Я посмотрел основные принципы ООП с точки зрения Алана Кея и не могу понять, чего он хотел.

Неудивительно. Изначально ООП было прежде всего идеей и не имело формального описания, такого как реляционная алгебра для РБД. То, что не имеет формального описания может быть по-разному трактовано и понято, или не понято вовсе.

Да. Этого нет.

Ошибаетесь. Есть аналог "сообщений" - это методы объектов. Вызов метода - это аналог посыла сообщения. Просто вы не привыкли рассматривать это с такой точки зрения. Например, в Objective C, в котором ООП смолтоковского стиля, так прямо и говорят. В языках с Simula-подобным ООП методы не называют сообщениями, т.к. в отличие от Smalltalk-стиля выбор кода для вызова (обработки метода/сообщения) выполняется компилятором, а не самим объектом.

Каждый объект имеет независимую память, которая состоит из других объектов

Пожалуй здесь речь идёт об инкапсуляции.

Стоп. Разве это не то, что я написал в пункте 4?

Нет. В пункте 4 вводится само понятие классификации - что среди неупорядоченного набора всевозможных объектов вы выделяете подмножества объектов, "похожих" друг на друга. Здесь ещё не идёт речи о том, будут ли у них общие методы или ещё что-то конкретно. Речь о самой идее выделения объектов во множества по каким-либо признакам. В пункте 5 уже делается заключение, что если уж мы выделили некоторое подмножество объектов, то грех этим не воспользоваться и не задать одно и то же поведение сразу для всего подмножества (грубовато описал, но как то так и есть).

Если у меня есть класс Dog, описывающий собаку, то от какого мифического единого общего класса она должна наследоваться?

System.Object. Да, вы уже от него унаследовались, прямо или через других предков. С точки зрения среды исполнения не всё чем вы оперируете, является объектом, например примитивные значения. Однако с точки зрения языка можно сказать что int "является объектом" т.к. значение int может быть приведено к типу object. От себя лично скажу, что целесообразность концепции "всё - объект" весьма сомнительна по ряду причин.

Если нет необходимости в множественных коннектах к БД, то SQLite - самое простое решение.

У DataAdapter-а проставить SelectCommand в select * from Classes where Класс=5

Превратите горизонтально-ориентированный StackPanel, т.е. тот, в котором у вас канвас, в DockPanel (тэг Orientation нужно будет убрать). Тогда ваш канвас, как последний из потомков, займёт всю оставшуюся доступную площадь (поведение по умолчанию). Плюс, это будет логично - ведь у вас управляющие контролы должны быть задоканы слева, поэтому логичнее использовать DockPanel.

С Новым Годом!

<DataGrid ...... AutoGenerateColumns="False">

https://msdn.microsoft.com/ru-ru/library/system.wi...

Ну и понятное дело у DataGridTextColumn нужно нормальные биндинги сделать.

Тот случай, когда не могу добавить что-либо к тому, что предлагал пару лет назад.

Но как можно понять, это учит лишь правильно держать карандаш, когда я хочу уметь рисовать.

Хорошо, что вы это понимаете.

Знаю о существовании книг и прочего по паттернам, но как по мне до этого еще чутка рановато, и нужно набить руку.

И это тоже хорошо, что понимаете. Сначала нужно столкнуться с проблемами, а потом искать решения в книгах - иначе это будет как для швеи книга по закаливанию стали.

Поставьте в ColumnDefinition вместо Auto значение 1*.
Также запретите листбоксу иметь горизонтальную прокрутку:

<ListBox Name="Test" Grid.Column="1" ScrollViewer.HorizontalScrollBarVisibility="Disabled">
 ...

1. Разработка крупных игровых проектов имеет как минимум те же особенности, что и разработка крупных приложений вообще. Раз вопрос о движках, не будем рассматривать прочие аспекты, такие как построение игровой модели, графический дизайн игры, написание сюжета и пр. Разработка движка, как большого проекта, требует:
- умение поставить начальные технические условия, которые будут заложены в архитектуру проекта (чтобы потом не было очень больно это всё менять);
- умение разбить движок на крупные подсистемы и выстроить между ними необходимые интерфейсы, чтобы каждую из подсистем отдать на разработку в отдельную команду;
- умение получить MVP в разумные сроки и строить дальнейшую разработку итеративно.

2. Как большой проект, связанный именно с компьютерной графикой, проект движка предполагает:
- что немалая часть кода будет писаться с учётом архитектурных особенностей аппаратуры - например, если ваш движок будет пытаться передавать слишком много данных по шине на видеокарту (постоянно гонять геометрию/текстуры), то скорость шины быстро станет узким местом и никакое новейшее оборудование вам не поможет.
- что графический код рано или поздно может потребовать мелких оптимизаций (вплоть до переписывания супернагруженных мест на ассемблере под каждую поддерживаемую аппаратную платформу);
- что графический код сегодня требует серьезного понимая физики света и цветовосприятия.

Для всех тех, кто понимает как реализовать вышеописанное, C++ и C# - лишь инструменты и жизненная необходимость, чтобы получить всё это, поэтому про знание языков даже говорить не буду, это подразумевается.

Конечно у вас будет один и тот же массив, вы ведь его один раз создали снаружи цикла.

В C# массив - ссылочный тип. Это значит что ваша переменная anyArr хранит в качестве значения ссылку (!) на массив. Если вы скопируете значение переменной, что вы по сути делаете в строке arrList.Add(anyArr); вы скопируете эту самую ссылку на массив, но не сам массив (в результате ссылка на один и тот же массив будет помещена в список 6 раз).

Если хотите иметь 6 разных массивов - создавайте их в цикле, или копируйте исходный, смотря что вам нужно делать. В любом случае, вам нужно 6 разных объектов типа object[] .

Затем читайте про типы-значения и типы-ссылки в C#.

Гуглите .NET Core / Mono.