ООП. Можно ли зацикливать классы ради быстродействия?

@OdIUm88 · Регистрация: 21.05.2019

Студворк — интернет-сервис помощи студентам

Добрый день!

Нужен совет касательно правильности придуманного мною подхода. Можно ли так делать или есть альтернативы.

Ситуация:

Как и две прошлые темы, продолжаю работать над генерацией геометрических объектов.

Для начала кратко о том, как устроена программа сейчас.

Кликните здесь для просмотра всего текста

Есть три основных эллемента:
1. Вершина (class Vertex)

C#
1
2
3
4
5
6
7
8
public class Vertex
    {
        private Vector3 position;                                                                                           // позиция вершины
        private Vector3 normal;                                                                                             // нормаль
        private Vector2 uv;                                                                                                 // координаты развертки
        private Vector3 tangent;                                                                                            // вектор касательная
        private Color32 color;      
}

2. Полигон (class Polygo)

C#
1
2
3
4
 public class Polygon 
    {
        private Vertex[] vertices;                             
}

3. Объект (Shape)

C#
1
2
3
4
5
public class Shape
    {
        private Vertex[] vertices;                                                                              // список вершин объекта
        private Polygon[] polygons;                                                                             // список полигона объекта
}

При генерации мы рассчитываем и создаем вершины, затем вершины соединяем в полигоны, затем из полигонов генерируем меш объекта.

Описание проблемы:

Кликните здесь для просмотра всего текста

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

Операция тяжелая, но выполняется всего один раз при генерации, а поэтому не слишком нагружала машину.

Но теперь, аналогичная информация (какие полигоны используют данную вершину) мне нужна для расчета векторов нормали (для обработки освещения).
Сохранять и использовать созданную в прошлом примере карту я не могу, так как:
1. Генерация карты вершин выполняется только для одного объекта - хексосферы
2. После генерации (как я писал ранее) карта устаревает.

При этом расчет нормалей может происходить довольно часто, так как объект может изменять положение своих вершин, а следовательно и пересчет необходим "на лету", что уже довольно сильно нагружает систему при многополигональных объектах.

Моя идея, которая похожа на решение, но, как мне кажется, нарушает ООП:

Кликните здесь для просмотра всего текста

1. Добавляем в класс Vertex список полигонов, которые ее используют.
2. В класс Polygon добавляем get set, которые при изменении списка вершин полигона корректируют список полигонов в вершинах.

Набрасываю код прямо тут, поэтому без оптимизации и циклов, просто как пример:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
public class Vertex
    {
        private Vector3 position;                                                                                           // позиция вершины
        private Vector3 normal;                                                                                             // нормаль
        private Vector2 uv;                                                                                                 // координаты развертки
        private Vector3 tangent;                                                                                            // вектор касательная
        private Color32 color;      
private List<Polygon> polygons;
}
 
 public class Polygon 
    {
        private Vertex[] vertices;    
public Polygon (Vertex v1, Vertex v2, Vertex v3){
vertices[0] = v1;
vertices[1] = v2;
vertices[2] = v3;
 
vertices[0].polygons.Add(this);
vertices[1].polygons.Add(this);
vertices[2].polygons.Add(this);
 
}                         
 
public Vertex[] Vertices {
 
get { return this.vertices; }                                                                          
set 
{ 
  vertices[0].polygons.Remove(this);
  vertices[0] = v1;
  vertices[0].polygons.Add(this);
 
  vertices[1].polygons.Remove(this);
  vertices[1] = v2;
  vertices[1].polygons.Add(this);
 
  vertices[2].polygons.Remove(this);
  vertices[2] = v3;
  vertices[2].polygons.Add(this);
}             
}
 
}

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

Или может быть подскажете более изящное решение?

@QuakerRUS · 22.07.2019, 12:31

Сообщение от OdIUm88

Моя идея, которая похожа на решение, но, как мне кажется, нарушает ООП

А в чем нарушение ООП? На первый взгляд вполне приемлемо.

@OdIUm88 · 22.07.2019, 12:48 **[ТС]**

Сообщение от QuakerRUS

А в чем нарушение ООП? На первый взгляд вполне приемлемо.

Ну то, что классы друг на друга ссылаются. Не думал что так можно)

@QuakerRUS · 22.07.2019, 13:14

Сообщение от OdIUm88

Ну то, что классы друг на друга ссылаются. Не думал что так можно)

Не вижу в этом проблемы. Можно. Даже нужно, иначе как еще запомнить связь вертекса с соседними полигонами? Не перебирать же все полигоны каждый раз.

@OdIUm88 · 22.07.2019, 13:18 **[ТС]**

Сообщение от QuakerRUS

Не вижу в этом проблемы. Можно. Даже нужно, иначе как еще запомнить связь вертекса с соседними полигонами? Не перебирать же все полигоны каждый раз.

Ну еще был вариант создать отдельный класс VertexMap и хранить эту информацию там.
Но заполнение и поддержка его актуальности сложнее и нагроможденнее выходит. Это более простой вариант, как кажется.

@QuakerRUS · 22.07.2019, 13:26

Сообщение от OdIUm88

Ну еще был вариант создать отдельный класс VertexMap и хранить эту информацию там.

Можно и так сделать. Это разгрузит класс самого вертекса от излишней информации. А в чем проблемы с заполнением и поддержкой? Если меняется положение вертекса, в этом классе никаких изменений не будет происходить. Изменения будут происходить, когда добавляется/удаляется вертекс и когда добавляется/удаляется соседний полигон. Более того сам этот класс сохранять не нужно при сохранении фигуры. При загрузке вертексов и полигонов его можно заново генерировать на этапе загрузки.

@OdIUm88 · 22.07.2019, 13:37 **[ТС]**

Сообщение от QuakerRUS

А в чем проблемы с заполнением и поддержкой?

Ну, в первом моем варианте, полигон сам все контролирует.
Во втором случае (с отдельным классом карты) нужно, как вы правильно заметили, отслеживать:
1. Удаление вершин
2. Изменения полигонов
3. Добавление вершин

А это происходит в разных местах программы.
В первом варианте реализации:
1. удалил вершину- удалил все связи
2. добавил новую вершину - связей нет
3. добавил связь (полигону указал на эту вершину) - полигон связь прописал

В общем все в одном месте, быстрее и удобнее.

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

@QuakerRUS · 22.07.2019, 14:24

Сообщение от OdIUm88

А это происходит в разных местах программы.

По идее у вас должны просто вызываться соответствующие методы, которые надо один раз переписать. Методы добавления/удаления точек и методы добавления/удаления полигонов. Итого 4 метода максимум.

@Элд Хасп · 22.07.2019, 14:27

Сообщение от OdIUm88

Во втором случае...

Полигоны же где-то у вас хранятся? Какой-то список или массив?
Создаёте свой собственный класс для хранения полигонов в котором определяете методы: Удаление вершин, Изменения полигонов и Добавление вершин.

В решениях могут применяться оба варианта - это зависит от деталей решения, оптимизации методов и других нюансов.

Но лично мне больше нравится подход с отдельным хранением связей. Это получается типичный граф. Для него есть множество типовых решений.

В первом варианте полигону (по сути вершине графа) требуется дополнительная информация о том, кто является его соседом. Эту информацию он может получить только от родительского объекта. Так если полигону надо за этой информацией обращаться к родителю, то почему тогда производную информацию в этом же родителе и не хранить?

Но в реальности возникают разные нюансы. Допустим, если информация о связях нужна чаще чем информация о вершинах то второй вариант однозначно предпочтительно.

Если же работа всегда идёт с отдельным полигоном их миллионы, и для каждого нужно быстрое получение списка соседей - то лучше первый вариант.

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

@OdIUm88 · 22.07.2019, 14:52 **[ТС]**

Здравствуйте, Элд Хасп!)

Сообщение от Элд Хасп

Полигоны же где-то у вас хранятся? Какой-то список или массив?

Да:

C#
1
2
3
4
5
public class Shape
    {
        private Vertex[] vertices;                                                                              // список вершин объекта
        private Polygon[] polygons;                                                                             // список полигона объекта
}

Сообщение от Элд Хасп

Создаёте свой собственный класс для хранения полигонов в котором определяете методы: Удаление вершин, Изменения полигонов и Добавление вершин.

Думал об этом, но по сути это опять же требует рефакторинга и может быть слишком много вариантов, которые сразу не учту.

Сообщение от Элд Хасп

Но в реальности возникают разные нюансы. Допустим, если информация о связях нужна чаще чем информация о вершинах то второй вариант однозначно предпочтительно.

Нет. Информация о вершинах используется чаще. Информация о том, в какие полигоны включена вершина, пока, для двух операций - генерации одного типа объекта + перерасчет нормалей

Сообщение от Элд Хасп

Если же работа всегда идёт с отдельным полигоном их миллионы, и для каждого нужно быстрое получение списка соседей - то лучше первый вариант.

Да, именно так. В основном идет работа с полигонами. Мы их двигаем, красим, изменяем.
Финальный меш генерируется именно по информации из полигонов.

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

Сейчас мне он кажется более простым и удобным, чем отдельное хранилище.

@Kazbek17 · 22.07.2019, 15:05

OdIUm88, А что вы делаете если не секрет, Может есть более другой подход. Просто нужно понять вашу картину.

@OdIUm88 · 22.07.2019, 15:13 **[ТС]**

Сообщение от Kazbek17

OdIUm88, А что вы делаете если не секрет, Может есть более другой подход. Просто нужно понять вашу картину.

Добрый день.

Это не секрет, конечно, но если не вдаваться в подробности - я попытался описать это в первом сообщении.
Сейчас попробую чуть подробнее объяснить.

Я пишу генератор объектов для Unity3d.
Т.е. есть входная точка для пользователя: ShapeBuilder и есть объект класса Shape.
Пользователь подключает библиотеку и пишет:
Shape shape = ShapeBuilder.GenerateSphere();
или
Shape shape = ShapeBuilder.GenerateHouse();

и т.д.

Далее у него в shape набор вершин и полигонов, который можно отобразить в игре в виде меша. Т.е. построить из него меш.
Для этого пользователь пишет:

Mesh mesh = shape.GenerateMesh();

И этот меш уже движок отображает как отдельный 3д объект игровой. Сфера или Дом (из примера).

Это общая концепция инструмента, который я пишу.
Конкретная задача описана в первом посте.

Да, я мог бы использовать стандартный инструмент юнити RecalculateNormals() для меша. Но это дороже и не гибко, так как сначала я создаю все точки, передаю все точки в меш, а потом еще раз по ним проходит юнити и считает нормаль. Так как объекты высокополигональные получаются - то решил сделать свои расчеты нормалей, чтобы в меш уже они попадали правильные.

Ну, как-то так.

@Элд Хасп · 22.07.2019, 21:39

Сообщение от OdIUm88

но из всего прочего, правильно ли я понимаю, что оба варианта можно использовать? И мой вариант, где в каждой вершине хранить информацию о полигонах - не является чем-то идиотским?)

Да, правильно.
Используйте тот который более оптимальный для вашего решения.

@NightmareZ · 23.07.2019, 13:01

Сообщение от OdIUm88

ООП. Можно ли зацикливать классы ради быстродействия?

Используй Dependency Injection. (шутка)

В таких задачах обычно не используют ООП, так как он тянет за собой большой оверхед.

Новые блоги и статьи Все статьи Все блоги /
Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Programma_Boinc 28.12.2025 Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Налог на собак: https:/ / ********/ gallery/ V06K53e Финансовый отчет в Excel: https:/ / ********/ gallery/ bKBkQFf Пост отсюда. . .	Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Нашел на реддите интересную статью под названием Anyone know where to get a free Desktop or Laptop? Ниже её машинный перевод. После долгих разбирательств я наконец-то вернула себе. . .	Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Programma_Boinc 23.12.2025 Рецензия / Мнение/ Перевод Нашел на реддите интересную статью под названием The Thinkpad X220 Tablet is the best budget school laptop period . Ниже её машинный перевод. Thinkpad X220 Tablet —. . .	PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.
Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .

@Kazbek17 1483 / 938 / 454 Регистрация: 06.02.2012 Сообщений: 2,868
	22.07.2019, 15:05
	OdIUm88, А что вы делаете если не секрет, Может есть более другой подход. Просто нужно понять вашу картину. 0