softwarerНасос - элемент коллекции. Ниппель - способ, которым коллекция взаимодействует с элементом. Именно его конструкцию мы и обсуждаем.

Забавно, насколько я помню начало топика - речь не шла: ни о коллекциях, ни о наполнении их (коллекций) какими-либо элементами.
Оченно даже наоборт - был предъявлен совершенно "абстрактный" (к контексту обсуждения, а не в терминах ООП) класс BaseClass с "простым" конструктором BaseClass(guid) и чуть более "продвинутый" наследник DerivedClass с "навороченным" конструктором DerivedClass(guid, guid, int), а также был вопрос - как избежать повторного кода в реализации этих конструкторов.
Насколько я смог понять аллегорию с мячами:
Мяч (мячи) - это экземпляры BaseClass и DerivedClass (должны быть наполнены "газом");
Газ (газы) - внутренние члены BaseClass и DerivedClass (коллекции, у BaseClass, например: одна, у DerivedClass - еще парочка к уже существующей от предка);
Насос (насосы) - метод для "накачки" мячей газом (сложная логика заполнения коллекций, вынесенная в отдельную функцию, вполне возможно существование 3-х различных "насосов" для каждой из описанных выше коллекций);
Ниппель (ниппели) - вспомогательный класс (фабрика, делегат), позволяющий получать результат работы "насоса" внутри конструктора "мяча", пока "мяч" еще не "инстацирован" (код не вышел за scope конструктора).

По-вашему, softwarer, получается, что - раз "ниппель" не нужен (отрезан бритвой Оккама), то "насос" должен быть помещен внутри "мяча", если не экземплярным методом, то хоть статическим, а если и статическим низзя, то тогда - методом внутреннего класса...
(кривовато как-то выглядит, ИМХО, даже на "насосно-газово-мячной" аллегории).

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

Кто уж тут занимается "крайне невнимательным чтением" или "изначальной одиозностью" (вот уж точно не понял - к чему ето ты про "одиозность" вставил, может значение слова не знаешь?) - не мне судить...

Однако ж, пересмотрев топик по ключевым словам еще раз, обнаружил следующее:
автор...Беда в том, что в конструкторе базового класса происходит добавление в некие коллекции неких элементов...
По-моему, здесь достаточно ясно русским по белому написано то, что не сами BaseClass и DerivedClass являются коллекциями (с твоей "легкой" руки), а заполняют эти коллекции внутри своих конструкторов? (-1).

maXno...то есть если, скажем, мы будем писать приложение для накачки мячей, мы в нём можем мяч и насос объединить в один класс, потому что мы можем так сделать?
maXno...а насос – это не элемент, это фабрика элементов (в моих терминах StuffFactory), ниппель – интерфейс (IStuffFactory), поддерживаемый всеми насосами и мячами. Элемент – это неизвестный газ (object), который каждый насос берёт неизвестно откуда, неизвестно как. И при накачке базовый мяч просто говорит в ниппель: «ещё газу », его не волнует, что за насос и что в него накачивают...
Отсюда я делаю вывод о том, что автором "мячно-газово-насосной" аллегории являешься не ты, однако же берешь на себя смелось интерпретировать чужие высказывания и учить других считать сущности... (-2).

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

Веди и впредь дискуссии в том же стиле и может быть когда-нибудь кто-то объяснит тебе значение слова "одиозность"...

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

Да уж, трудно врубиться в то, что элемент коллекции оказывается для нее - "снаружи, отделимый и независимый"... или ты свой собственный русский язык изобрел?

softwarerочередной представитель серого племени серых ников...

Не суди и не судим будешь...
(например: судя по тому, что ты не процитировал мои высказывания про "одиозность" - таки не знаешь значения этого слова, а еще за "учительниц в школе" пытаешься выступать, с собой сначала разберись, сиятельный "зарегистрированный член форума").

BrokenPot...Извините за сложносочиненность моих предложений...

Меня не напрягает (я умею читать и писать по-русски), а softwarer-у - по-боку (его никакие другие мнения, кроме своего собственного, изначально непогрешимого, не "вставляют").

BrokenPot...Аналогия же с мячами ... изложена весьма путанно, с некоторой подменой понятий по ходу дела...

"Подмена понятий" - это, опять же, к softwarer-у (его "изначально одиозный" приемчик), я всего-навсего другими словами и в одном посте изложил то, что у maXno (как автора идеи) было "размазано" по нескольким постам.
Заменять сущности базовых классов коллекциями, засовывать "насосы" внутрь "мячей", притягивать за уши "отчуждаемость" элемента коллекции от ее самое - это очень показательный уровень "настройки машины логического вывода" с его стороны.

BrokenPot... Поэтому я не до конца понимаю, о чем же, все-таки, спорят собеседники...

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

2softwarer: Иногда люди не дают себе труда возражать на откровенную белиберду, т.к. им жалко тратить на это бесцельное занятие свое драгоценное время (я - печальное исключение из этого "банального" правила).
Однако, мне все ж таки интересно как ты, как гигант мысли и великий настройщик машины логического вывода, сможешь убедительно "отчуждить" тип int от коллекции IList<int>, например?
Так, чтобы всем было доступно понятно - int находится "внутри" IList<int> или "вне ее"?
(и не заводи опять бодягу с притягиванием за уши конкретных экземпляров в конкретных ячейках коллекции, никто и не собирался сомневаться в том, что экземпляр может быть выкинут из коллекции без следа).

softwarer...Во-первых, не путай типы и экземпляры (они же классы и объекты).

Ну, примерно такого именно ответа я от тебя и ожидал, куда уж нам с нашей серостью отличить "насос" (тип/элемент/экземпляр?) от "мяча" (класс/коллекция/контейнер?).
Это только блистательным гигантам мысли и мастерам настройки машин логического вывода (без водителей) позволено запросто "отождествлять" элемент коллекции (суть - экземпляр) с каким-то непонятным "насосом" (почему-то обозванным потом типом), класс BaseClass ("мяч" без возражений с твоей стороны, суть - тип) с коллекцией (она же - экземпляр контейнера, из которого "водитель" может выйти и не вернуться).

softwarer...Тип int определенно находится "вне" любой коллекции, он описан совершенно отдельно.

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

softwarerОтветь сам себе на два простых вопроса:

Сможет ли коллекция IList<int> принять в себя экземпляры типов отличных от int (без передергивания к наследникам, что слава БГ, для int и невозможно)?

Если не сможет, сможешь ли ты заставить ее это сделать, когда будет такая потребность?

Если ответом на оба вопроса будет "да" - ты прав, тип int отчуждаем (не сам по себе, как сферический конь от вакуума) от коллекции IList<int>. Для тебя.

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

Х-хоспаде, да кому ты нужен со своими "харизмой" (от базарной бабы) и "интеллектом" (от Шарикова П.П.), я ничего и не собирался доказывать тебе лично ("ежу понятна безнадежность"), а уж тем более не представлял тебя идиотом (ты с этим и сам прекрасно справляешься).
А ввязался я в дискуссию только затем, чтобы люди читающие эту ветку не глотали "на веру" (потому что - "никто не возразил", © твой) ту кашу из понятий, которую ты тут щедро выливаешь из своей забитой помоями головы.
И то, что ты "некомпетентен в .NET", зато очень "компетентен" в дельфах (можешь "отождествить" при случае нетипизированную коллекцию указателей на все на свете TList со строго типизированной по содержмому IList<int>), не дает тебе никакого бонуса в этом споре, т.к. только лишний раз показывает уровень твоего "интеллекта" и забитость твоей головы кашей из понятий, постепенно переваривающихся в помои.
Очень удобная позиция - там где это выгодно прикинуться дурачком, не знающим и не желающим знать синтаксиса generic-ов в C#2.0, и на этом основании вещать о возможностях типизированных коллекций как о возможностях нетипизированных.
Зато в другом месте, можно и "интеллект" проявить - напихать в "мяч" (коллекцию) "насосов" (элементов коллекции) и гордиться собственной "харизмой" и удачностью аналогии, попинывая радостно под столом мяч набитый насосами под завязку.

Если хочешь продожать разговор "по теме", то прежде всего - избавь свой лексикон от понятий и терминов, не имеющих никакого отношения к ООА ("отчуждаем", "извне" и т.п.), потому что это заводит людей, пытающихся тебя понять и обсудить вопрос "по существу" в дебри терминологических споров.
Нет никакой "отчуждаемости" в отношениях между типами (классами), есть "зависимость", вполне адекватный термин, в обсуждении которого противоречий быть не может:
int НЕ зависит от IList<int>;

IList<int> ЗАВИСИТ от int;
И в этой (второй) зависимости ни один из типов не может быть "отчужден" от другого. Зависимость - суть связь, понятие двусторонее по определению.
Нет зависимости - нет связи, ничто не задает ограничение по типу элементов коллекции, следовательно - IList<int> перестает существовать и "вырождается" в TList.

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

2all:
С наступающим Новым Годом, друзья!!
Всем - пока... (из этого топика).