Как проектировать значимые объекты и их отношения в простых физических симуляциях

Я пытаюсь разработать несколько простых живых симуляций, используя парадигму ООП. Проблема, с которой я столкнулся, заключается в том, что из-за отсутствия у меня опыта в этом подходе я не знаю, как естественным образом определить «правильные» объекты и их отношения. Таким образом, мой вопрос ближе к архитектуре программного обеспечения, а не к более техническому вопросу «как можно добиться того или иного». Обратите внимание, что я делаю это упражнение именно для того, чтобы узнать об этой парадигме программирования.

Моделирование пытается разрешить взаимодействие (столкновения, притяжение и т. д.) между частицами в пустом 2D-пространстве. Первый объект, который приходит мне на ум, это Particle. Я реализовал этот класс с положением, скоростью, массой и т. д. Я создал методы для их инициации, обновления их положения (в соответствии с некоторыми физическими правилами) или даже рисования их на холсте. Теперь моя проблема возникает при установке физических констант или параметров печати (размер холста, номер окна, количество кадров в секунду и т. д.). Прямо сейчас я использую глобальные переменные, такие как гравитация или размер холста. Это то, что можно было бы сделать в подходе, отличном от ООП, и это работает до сих пор. Но я изо всех сил пытался понять, как чистое ООП справится с этими общими параметрами среди частиц. Я могу предвидеть разные варианты.

  1. Я мог бы создать класс Canvas с графическими параметрами и Universe с такими константами, как гравитация. Тогда класс Particle будет расширенным классом. Но от кого я должен унаследовать? Тем не менее, класс будет расширен, но не сами объекты...
  2. Другим вариантом может быть создание Universe и Particle как независимых классов. Затем я бы связал их, создав уникальный объект Вселенной. Каждая частица будет содержать указатель на такой объект Вселенной, поэтому они имеют доступ к физическим параметрам. Я не уверен, что этот подход с указателем вообще является ООП...

Хотя я знаю, что есть много способов сделать это, мне интересно, есть ли один, который является более интуитивным и «стандартным», по крайней мере, с академической точки зрения. Я предполагаю, что это не включено в решения, которые я предлагаю, поэтому любой намек на то, как спроектировать структуру в этом типе простых симуляций, будет очень кстати.


person Onturenio    schedule 07.03.2016    source источник
comment
Будьте осторожны: может быть трудно совместить ООП и производительность. programmers.stackexchange.com /вопросы/125753/   -  person Anthony Scemama    schedule 08.03.2016


Ответы (1)


Это более практичный взгляд на это, в основном из моего собственного опыта, и строго на уровне основных соображений дизайна. Я был бы так же заинтересован в обратной связи.

Во-первых, с точки зрения дизайна ваши "Canvas" и "Universe" кажутся разными: я могу себе представить, что параметры Canvas могут потребоваться изменить. , в то время как физические константы, по-видимому, не будут.

Если предположить, что объекты Canvas могут меняться, для меня это будет отдельный класс. Я не вижу, чтобы вы хотели, чтобы ваша Particle наследовалась от этого; в моем понимании это логически совершенно отдельные сущности. Что касается удобства размещения частиц на холсте, я бы обработал это на другом уровне, а не по наследству.

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

Что касается фиксированных параметров, я использовал отдельные заголовочные файлы с явными пространствами имен в C++ проектах. Я не вижу причин, по которым в Фортране было бы невозможно использовать отдельный модуль с константами. В этом смысле они глобальны, но это можно контролировать при использовании, и это то, чем они являются. В этом подходе также есть гибкость, если ваш набор (ы) констант становится более сложным, чем просто несколько чисел. Кроме того, вы можете позже поднять это до класса, если в этом будет продемонстрирована необходимость.

Затем возникают вопросы о том, как именно они соотносятся с другими классами, и о многих деталях их написания. Это задало бы вопрос в другом месте, и я не так хорошо знаком с полными возможностями объектно-ориентированного программирования Fortran (кроме написания классов).

Итак, я бы сказал: "Canvas" — это класс, а "Universe" — модуль, оба отдельные от Particle.

person zdim    schedule 08.03.2016
comment
Спасибо за ответ. Тем не менее меня беспокоит, как мне связать Universe и Canvas? Я приведу простой пример: реальная проблема, с которой я столкнулся, заключается в том, что у холста есть идентификатор, который идентифицирует окно (этот идентификатор используется для низкоуровневых подпрограмм рисования). У меня есть метод в Particle, который рисует круг в заданных координатах, но ему нужен такой идентификатор. Как я могу заставить частицу осознавать тот факт, что она живет в данном Canvas? В моей текущей реализации такой идентификатор является частью класса Particle, что я считаю неудачным решением. - person Onturenio; 10.03.2016
comment
@Onturenio Я бы не стал учитывать эти соображения на уровне дизайна. Почему Particle запутался с Canvas? Это просто заговор, да? Canvas не влияет на его поведение, верно? Если ему нужно знать о свойствах Canvas — ну, Canvas — это класс с разработанным вами интерфейсом (методы доступа), так что каждый может получить информацию, которая может ему понадобиться. Вы можете интегрировать их более тесно, но делать их частью цепочки наследования другого кажется мне неподходящим. - person zdim; 11.03.2016
comment
@Onturenio Я столкнулся с этим интересным вопросом, просматривая свои старые посты. Что ты в итоге сделал? Я бы также предложил опубликовать это в качестве ответа для будущих посетителей этой страницы. (Это нормально, если оно короткое и ваше собственное, если оно лучшее.) - person zdim; 25.06.2016