ООП. Некоторые аспекты, неясные новичку. Ruby.

Возникло желание и небольшая надобность сделать веб-морду для одной БД. Решил использовать RoR, т.к. хочется изучить что-то новое на относительно несложном проекте.

Сразу скажу, что ООП для меня — тёмный лес, не потому, что читать умные книжки не умею, а из-за того, что никак не пойму его сути и условий применения. Вот, к примеру, нынешний проект. Для простоты предположим, что мы собираем буратин и продаем их.

Надумал пару вариантов:

Первый.

У нас есть класс A, описывающий некие детали, положим, что свойствами этого класса будут название детали и её масса. В РоР создаваемые объекты класса могут заноситься в таблицу, т.о. получается, что создав объект класса А мы автоматом получаем таблицу деталей.

Есть класс B — это сами буратины. Если его сделать наследником класса A, то он будет иметь свойствами как название так и массу. Существует необходимость для объекта класса B указать перечень деталей, его составляющих, значит, третьим свойством этого класса будет массив объектов класса A. Причем, этот массив может быть и пустым, это просто означает, что буратино стандартный и его конструкцию можно посмотреть в справочнике.

И, наконец, есть класс C — накладная. Он вроде бы ничего не наследует, но свойствами его, помимо массива объектов класса B, должен быть массив такой же размерности, содержащий в себе количество буратин по каждой позиции. Прочие свойства типа даты и «чего-там-душа-пожелает» тривиальны.

Недостаток этого варианта вижу в том, что используется слишком много массивов, быстро будет расходоваться память, особенно на операциях вида «вывести на экран все накладные от даты №1 по дату №2», также будут тормозить вычисления количества проданных экземпляров и тд.

Второй

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

Создаем класс Б, такой же, как класс С в первом варианте. Здесь увеличивается количество дублирующей информации в базе, зато вроде шустрее должно работать.


Что из вышеперечисленного неверно и что можно сделать лучше?

Используется не массив как таковой, а связь "многие-ко-многим". Попробуй посмотреть в документации РоР - many to many (m2m), или ещё как-нибудь так. Я могу написать приблизительный код на Django, но РоР (да и вообще Руби) я не знаю.

Оптимальное решение на мой взгляд такое.

1. Объект «деталь».

2. Объект «буратино», имеющий привязки к объектам «детали».

3. Объект «накладная» с нужными связями.

Наследования как такового нет.

Наследование, вообще, нужно в том и только том случае, когда дочерний объект является небольшим расширением или модификацией родительского, но принципиально в нём ничего не меняется.

Буратино - не является наследником его деталей

Но может быть, например, класс «Деревянная кукла», наследниками которой будут «Буратино» и «Пиноккио».

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

Ромин пост понял, Серегины пока нет, но пытаюсь понять.