ООП / Программирование

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

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

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

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Программирование [игнор отключен] [закрыт для гостей] / ООП

47 сообщений из 47, показаны все 2 страниц

все

ООП

#34209780

BrokenPot

Участник

Откуда: Киев

Сообщения: 1 364

Рейтинг: 0 / 0

Имеется базовый класс BaseClass.

У базового класса имеется конструктор с одним параметром New(id as guid)

Возникла необходимость в создании класса-наследника DerivedClass

Однако выходит так, что у класса-наследника должен быть конструктор с тремя параметрами New(id as guid, idperiod as guid, idbranch as integer)

...

Рейтинг:

0 / 0

19.12.2006, 11:25

| Ответить | Цитировать | Написать

ООП

#34209794

BrokenPot

Участник

Откуда: Киев

Сообщения: 1 364

Рейтинг: 0 / 0

Не могу сообразить, как такое следует делать, не переписывая целиком весть конструктор.

...

Рейтинг:

0 / 0

19.12.2006, 11:26

| Ответить | Цитировать | Написать

ООП

#34209902

(меня всё равно забанят)

Гость

BrokenPotИмеется базовый класс BaseClass.

У базового класса имеется конструктор с одним параметром New(id as guid)

Возникла необходимость в создании класса-наследника DerivedClass

Однако выходит так, что у класса-наследника должен быть конструктор с тремя параметрами New(id as guid, idperiod as guid, idbranch as integer)

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

 class  BaseClass {

  public  BaseClass(id as guid) {
   bla-bla-bla...
 }
}



 class  DerivedClass extend BaseClass {
  private  DerivedClass(id as guid) {
   bla-bla you can't use that, haha
 }
  public  DerivedClass(id as guid, idperiod as guid, idbranch as integer) {
   bla-bla-bla...
 }
}

...

Рейтинг:

0 / 0

19.12.2006, 11:49

| Ответить | Цитировать | Написать

ООП

#34209994

BrokenPot

Участник

Откуда: Киев

Сообщения: 1 364

Рейтинг: 0 / 0

То есть, нужно все-таки наново переписывать весь конструктор?

...

Рейтинг:

0 / 0

19.12.2006, 12:10

| Ответить | Цитировать | Написать

ООП

#34210018

(меня всё равно забанят)

Гость

BrokenPotТо есть, нужно все-таки наново переписывать весь конструктор?
Бозе мой.
Ну напиши

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.

 class  DerivedClass extend BaseClass {
  private  DerivedClass(id as guid) {
    super (id);
 }

  public  DerivedClass(id as guid, idperiod as guid, idbranch as integer) {
   bla-bla-bla...
 }
}

...

Рейтинг:

0 / 0

19.12.2006, 12:17

| Ответить | Цитировать | Написать

ООП

#34210508

fixxer

Участник

Сообщения: 805

Рейтинг: 0 / 0

(меня всё равно забанят) BrokenPotТо есть, нужно все-таки наново переписывать весь конструктор?
Бозе мой.
Ну напиши

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.

 class  DerivedClass extend BaseClass {
  private  DerivedClass(id as guid) {
    super (id);
 }

  public  DerivedClass(id as guid, idperiod as guid, idbranch as integer) {
   bla-bla-bla...
 }
}

тогда уж так

Код: plaintext

1.
2.
3.
4.
5.
6.
7.

 class  DerivedClass extend BaseClass {
 
  public  DerivedClass(id as guid, idperiod as guid, idbranch as integer) {
    super (id);
   bla-bla-bla...
 }
}

...

Рейтинг:

0 / 0

19.12.2006, 14:16

| Ответить | Цитировать | Написать

ООП

#34210555

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

BrokenPotНе могу сообразить, как такое следует делать, не переписывая целиком весть конструктор.
Вызывать (использовать) прежний из нового. Как это делать - см. описание используемого языка.

...

Рейтинг:

0 / 0

19.12.2006, 14:27

| Ответить | Цитировать | Написать

ООП

#34210617

BrokenPot

Участник

Откуда: Киев

Сообщения: 1 364

Рейтинг: 0 / 0

Беда в том, что в конструкторе базового класса происходит добавление в некие коллекции неких элементов.

Это происходит с использованием параметра, передаваемого в конструктор базового класса.

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

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

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

...

Рейтинг:

0 / 0

19.12.2006, 14:46

| Ответить | Цитировать | Написать

ООП

#34210858

(меня всё равно забанят)

Гость

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

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.

class DerivedClass extend BaseClass {
 private DerivedClass(id as guid) {
   super(id);
 }

 public DerivedClass(id as guid, idperiod as guid, idbranch as integer) {
   bla-bla-bla...
 }
}

Обратите особое внимание на модификаторы видимости.
В объекте-наследнике доступ к конструктору с одним параметров в приинципе запрещен извне.
Что вы баламутите? :)

...

Рейтинг:

0 / 0

19.12.2006, 15:53

| Ответить | Цитировать | Написать

ООП

#34210928

BrokenPot

Участник

Откуда: Киев

Сообщения: 1 364

Рейтинг: 0 / 0

Я не баламутю.

А в тебе бла-бла-бла присутствует вызов конструктора базового класса?

...

Рейтинг:

0 / 0

19.12.2006, 16:13

| Ответить | Цитировать | Написать

ООП

#34210932

BrokenPot

Участник

Откуда: Киев

Сообщения: 1 364

Рейтинг: 0 / 0

в теле

...

Рейтинг:

0 / 0

19.12.2006, 16:14

| Ответить | Цитировать | Написать

ООП

#34211286

(меня всё равно забанят)

Гость

BrokenPot
А в теле бла-бла-бла присутствует вызов конструктора базового класса?
Хм...

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

Код: plaintext

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.

 public   class  xtest
{
     public  xtest()
    {
        BaseClass base =  new  BaseClass( 4 );
        ExtClass ext =  new  ExtClass( 2 , 5 , 3 );
    }
    
    
     public   static   void  main(String args[]) {
        xtest t =  new  xtest();
    }

}


 class  BaseClass
{
     protected  BaseClass() {
        // do nothing
    }
    
     public  BaseClass( int  a)
    {
        System.out.println("a = " + a);
    }
}


 class  ExtClass  extends  BaseClass
{
     public  ExtClass( int  a,  int  b,  int  c) 
    {
        System.out.println("a = " + a + ", b = " + b + ", c = " + c);
    }
}

Либо, как вариант

Код: plaintext

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.

 public   class  xtest
{
     public  xtest()
    {
        BaseClass base =  new  BaseClass( 4 );
        ExtClass ext =  new  ExtClass( 2 , 5 , 3 );
    }
    
    
     public   static   void  main(String args[]) {
        xtest t =  new  xtest();
    }

}


 class  BaseClass
{
    
     public  BaseClass( int  a)
    {
         if  (a !=  0 ) {
            System.out.println("a = " + a);
        }
    }
}


 class  ExtClass  extends  BaseClass
{
     public  ExtClass( int  a,  int  b,  int  c) 
    {
         super ( 0 );
        System.out.println("a = " + a + ", b = " + b + ", c = " + c);
    }
}

...

Рейтинг:

0 / 0

19.12.2006, 18:08

| Ответить | Цитировать | Написать

ООП

#34211640

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

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

Вообще, отмечу, создание элементов коллекции в конструкторе коллекции и только там - малость странная постановка вопроса. Но тем не менее.....

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

Тут возникает вопрос, как передать параметры. Есть два метода. Первый - через локальные поля; конструктор наследника запоминает параметры, вызывает базовый, тот строит коллекцию, вызываемый при этом виртуальный метод читает поля. Второй - сделать объект "параметры инициализации" и передавать именно его.

...

Рейтинг:

0 / 0

19.12.2006, 21:59

| Ответить | Цитировать | Написать

ООП

#34212039

BrokenPot

Участник

Откуда: Киев

Сообщения: 1 364

Рейтинг: 0 / 0

О! Спасибо большое.

Рад получить содержательный и исчерпывающий ответ.

Особенно приятно, что он совпал с моими соображениями, которые появились, пока я ожидал ответа.

...

Рейтинг:

0 / 0

20.12.2006, 09:18

| Ответить | Цитировать | Написать

ООП

#34213579

maXmo

Участник

Откуда: Моск.

Сообщения: 8 515

Рейтинг: 0 / 0

имхо, нужно делать через параметры инициализации, а то вызывать метод для ещё неинициализированного объекта – как-то не очень…

...

Рейтинг:

0 / 0

20.12.2006, 15:13

| Ответить | Цитировать | Написать

ООП

#34213898

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

maXmoимхо, нужно делать через параметры инициализации, а то вызывать метод для ещё неинициализированного объекта – как-то не очень…
Ничуть не более, нежели делать с "еще не инициализированным объектом" что-то другое.

Подозреваю, Вы отталкиваетесь от явы, то как сделана инициализация там, меня, если честно, напрягает, по разным причинам. В частности, я уже приводил этот код:

Код: plaintext

1.
2.
3.
4.

 public  SomeClass  extends  BaseClass {
   public  SomeClass ( int  i) {
     super  ((i ==  1 ) ? "a" : "b");
  }
}

Код: plaintext

1.
2.
3.
4.
5.

 public  SomeClass  extends  BaseClass {
   public  SomeClass ( int  i) {
    String s = (i ==  1 ) ? "a" : "b";
     super  (s);
  }
}

Я понимаю, почему компилятор ругается на второй вариант, но полагаю такое поведение глупым.

...

Рейтинг:

0 / 0

20.12.2006, 16:27

| Ответить | Цитировать | Написать

ООП

#34214017

maXmo

Участник

Откуда: Моск.

Сообщения: 8 515

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

20.12.2006, 16:52

| Ответить | Цитировать | Написать

ООП

#34214356

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

maXmoпросто это как-то интуитивно нехорошо – вызывать какие-то левые методы до того, как конструктор отработает.
Левых методов в классе быть вообще не должно.

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

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

Можно вести речь о том, какие подпрограммы правильно либо неправильно вызывать из конструктора. Тут мне ява когда-то подкинула забавный сюрприз. Код был примерно следующим:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.

 public  BaseClass {
   public  BaseClass() { ...; someVirtualMethod(); ...}
   public  someVirtualMethod(); { ... }
}

 public  DerivedClass {
   private  Vector someData =  null ;
   public  DerivedClass() {  super (); .... }
   public  someVirtualMethod() { ....  if  (someData ==  null ) someData =  new  Vector(); ... }
}

Прикол этого кода был в том, что в результате его выполнения сначала был вызван конструктор базового класса, он вызвал виртуальный метод и инициализацию someData, а только потом отработало присваивание someData = null. Особой логики я в таком поведении не вижу, имхо неудачная калька с C++ как раз там, где стоило чуть изменить модель. В Java5, если мне не изменяет память, как раз из-за подобных эффектов рубанули топором и компилятор стал ругаться на вполне разумный код, пришлось придумывать обходы.

...

Рейтинг:

0 / 0

20.12.2006, 18:51

| Ответить | Цитировать | Написать

ООП

#34215521

maXmo

Участник

Откуда: Моск.

Сообщения: 8 515

Рейтинг: 0 / 0

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

softwarerСкажем, в примере выше - придумать функтор "создатель элементов коллекции" и передавать его в базовый конструктор. Формально это уже не собственный метод объекта, фактически - кривизна на пустом месте.если нужно создать объект почти произвольного типа, ответ один – фабрика. Если хочется ограничения видимости, фабрику можно сделать в виде класса, вложенного в DerivedClass из твоего примера, можно даже с модификатором private. Но тут это не понадобилось, т.к. чел хотел всё сделать в одном месте – в базовом конструкторе обобщённой формы… получилось сделать.

...

Рейтинг:

0 / 0

21.12.2006, 11:44

| Ответить | Цитировать | Написать

ООП

#34215815

NotGonnaGetUs

Участник

Откуда: Москва

Сообщения: 1 782

Рейтинг: 0 / 0

[quot softwarerПодозреваю, Вы отталкиваетесь от явы, то как сделана инициализация там, меня, если честно, напрягает, по разным причинам. В частности, я уже приводил этот код:
...
Я понимаю, почему компилятор ругается на второй вариант, но полагаю такое поведение глупым.[/quot]

Ага, во всех грехах виновата java %)

з.ы.
Тоже самое сделано в языках .NET, потому что это правильно.

...

Рейтинг:

0 / 0

21.12.2006, 13:03

| Ответить | Цитировать | Написать

ООП

#34217234

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

maXmoсогласен. Если нужно. Но тут явно была задача на написание конструктора в более общей форме.
"Как оптимально решать данную конкретную задачу" можно обсуждать; пока кроме моего никаких предложений не прозвучало.

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

maXmoесли нужно создать объект почти произвольного типа, ответ один – фабрика.
Я не очень понимаю, что такое "объект почти произвольного типа", и во всяком случае задача "создать указанного наследника базового типа" - имхо к таковым не относится. И это одна из наиболее типичных задач в ООП.

Далее, у меня нет уверенности в том, что я понимаю, что Вы называете "фабрикой". Точнее, разные люди при мне определяли это понятие с существенными различиями. Если понимать фабрику как некий выделенный объект, то это очевидно не единственный ответ и очень далеко не факт, что лучший.

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

В целом у меня есть ощущение, что Вы советуете как раз то, что я склонен считать нагромождением "сложностей" на пустом месте.

...

Рейтинг:

0 / 0

21.12.2006, 20:26

| Ответить | Цитировать | Написать

ООП

#34217244

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

NotGonnaGetUsАга, во всех грехах виновата java %)
Прошу прощения, но по-моему у Вас mania grandioso.

...

Рейтинг:

0 / 0

21.12.2006, 20:30

| Ответить | Цитировать | Написать

ООП

#34218218

maXmo

Участник

Откуда: Моск.

Сообщения: 8 515

Рейтинг: 0 / 0

softwarerНо здесь я сосредоточился на более узкой теме, вызове подпрограммы из конструктора как идее. Я так понимаю, мы пришли к согласию в том, что это может быть уместно.ну если ограничиться более узкой темой softwarerСкажем, в примере выше - придумать функтор "создатель элементов коллекции" и передавать его в базовый конструктор. Формально это уже не собственный метод объектая же предлагаю этот несобственный метод объекта выделить в другой класс, в котором он будет собственный и в котором он будет вызываться на уже сконструированном объекте.

softwarerЯ не очень понимаю, что такое "объект почти произвольного типа", и во всяком случае задача "создать указанного наследника базового типа" - имхо к таковым не относится. И это одна из наиболее типичных задач в ООП.под фабрикой я понимаю объект, создающий наследников базового класса. Создавать же указанных наследников можно просто оператором new, нет?

softwarerЕсли понимать фабрику как некий выделенный объект, то это очевидно не единственный ответ и очень далеко не факт, что лучший.ну… выделяешь ты эту логику в отдельный класс или не выделяешь, в любом случае роль фабрики выполняет тот класс, в котором этот метод содержится. Почему бы не выделить эту логику в отдельный класс? Разве это не логично? Мне это видится логичным; это распространённый метод, к тому же исчезнут всякие сюрпризы с конструкторами.

softwarerВложенный класс инициализируется указателем на объемлющийвовсе не обязательно.

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

...

Рейтинг:

0 / 0

22.12.2006, 11:39

| Ответить | Цитировать | Написать

ООП

#34218497

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

maXmo softwarerСкажем, в примере выше - придумать функтор "создатель элементов коллекции" и передавать его в базовый конструктор. Формально это уже не собственный метод объектая же предлагаю этот несобственный метод объекта выделить в другой класс,
Хм. "Функтор" - это и есть "другой класс".

maXmoпод фабрикой я понимаю объект, создающий наследников базового класса. Создавать же указанных наследников можно просто оператором new, нет?
Оператором new можно создавать статически указанных наследников. Если не ошибаюсь,

Код: plaintext

 Class  c = some.getClass();
Object o =  new  c();

в яве не пройдет, да и в C++ тоже.

maXmoв любом случае роль фабрики выполняет тот класс, в котором этот метод содержится. Почему бы не выделить эту логику в отдельный класс? Разве это не логично? Мне это видится логичным; это распространённый метод, к тому же исчезнут всякие сюрпризы с конструкторами.
То есть Вы понимаете фабрику примерно как я ожидал.

Описанное выделение - совершенно не факт, что логично. По общему принципу Оккама, наоборот, нужно доказывать, что оно в данном конкретном случае дает преимущества. Насчет распространенности метода.... скажем так, он распространен только потому, что закрывает один из концептуальных недостатков C++, который там никак иначе не решишь (разве что в последних версиях).

maXmo softwarerВложенный класс инициализируется указателем на объемлющийвовсе не обязательно.
Будем считать, Вам виднее. Для меня это новость.

maXmoмне видится, что место совсем не пустое. Либо пишешь метод, который не меняет состояний окружающих объектов (и не зависит от них), либо одно их двух.
Хм. Давайте так: я сейчас не хочу спорить по этому поводу. Предложите топикстартеру свое решение, пусть делает как ему больше понравится.

...

Рейтинг:

0 / 0

22.12.2006, 12:31

| Ответить | Цитировать | Написать

ООП

#34218724

maXmo

Участник

Откуда: Моск.

Сообщения: 8 515

Рейтинг: 0 / 0

softwarerПо общему принципу Оккама, наоборот, нужно доказывать, что оно в данном конкретном случае дает преимущества.то есть если, скажем, мы будем писать приложение для накачки мячей, мы в нём можем мяч и насос объединить в один класс, потому что мы можем так сделать?

softwarerБудем считать, Вам виднее. Для меня это новость.

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

class DerivedClass: BaseClass
{
 class StuffFactory: IStuffFactory
 {
  public object GiveMeMyStuff()
  {
   return Random.Next(); //но вообще тут может любой объект создаться
  }
 }
 public DerivedClass(): base(new StuffFactory()) //BaseClass(IStuffFactory)
 {
 }
}

softwarerПредложите топикстартеру свое решение, пусть делает как ему больше понравится.да он уже удовлетворён.

...

Рейтинг:

0 / 0

22.12.2006, 13:22

| Ответить | Цитировать | Написать

ООП

#34222015

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

maXmoто есть если, скажем, мы будем писать приложение для накачки мячей, мы в нём можем мяч и насос объединить в один класс, потому что мы можем так сделать?
Неудачная аналогия для данного случая. Точнее так: есть мяч (базовый класс коллекции, производный класс коллекции, о которых мы говорим). Есть насос (базовый-производный класс элементов). И есть ниппель (переходник между ними, который мы и обсуждаем).

Вы полагаете, что ниппель необходимо выделять в отдельный класс. Я пока что такой необходимости не вижу. Она может появиться - например, если по условиям задачи могут появиться одинаковые мячи с разными ниппелями. Может не появиться.

maXmoclass DerivedClass: BaseClass
Это на C#? К сожалению, я его не знаю и не собираюсь ничего утверждать; в моей фразе подразумевалась реализация вложенных классов в Java. Сожалению, что не обозначил это четко.

...

Рейтинг:

0 / 0

25.12.2006, 11:35

| Ответить | Цитировать | Написать

ООП

#34222810

maXmo

Участник

Откуда: Моск.

Сообщения: 8 515

Рейтинг: 0 / 0

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

softwarerЭто на C#? К сожалению, я его не знаю и не собираюсь ничего утверждать; в моей фразе подразумевалась реализация вложенных классов в Java. Сожалению, что не обозначил это четко.ну… можно и не вкладывать класс насоса в класс мяча, а будет просто глобальная куча насосов, из которых каждый мяч будет выбирать свой.

...

Рейтинг:

0 / 0

25.12.2006, 15:03

| Ответить | Цитировать | Написать

ООП

#34222903

grexhide

Участник

Откуда: Страна непреодолимых противоречий

Сообщения: 8 821

Рейтинг: 0 / 0

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

"Построители виртуальных миров" в действии ??? ;)))

Кстати, ты не понял вообще, о чем говорил softwarer.

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

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

...

Рейтинг:

0 / 0

25.12.2006, 15:20

| Ответить | Цитировать | Написать

ООП

#34222926

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

maXmoИ при накачке базовый мяч просто говорит в ниппель: «ещё газу», его не волнует, что за насос и что в него накачивают.
Если обратите внимание, в моем решении этот принцип полностью соблюден. Это важно, он ключевой.

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

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

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

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

...

Рейтинг:

0 / 0

25.12.2006, 15:23

| Ответить | Цитировать | Написать

ООП

#34223360

maXmo

Участник

Откуда: Моск.

Сообщения: 8 515

Рейтинг: 0 / 0

softwarer maXmoИ при накачке базовый мяч просто говорит в ниппель: «ещё газу», его не волнует, что за насос и что в него накачивают.
Если обратите внимание, в моем решении этот принцип полностью соблюден. Это важно, он ключевой.хм… да, но не он у нас камень преткновения, а вызов метода на несконструированном объекте (в процессе его конструирования). Я не отрицаю, что это можно реализовать. Можно, если не лень потом будет разгребать там ясно-какие-баги.

softwarerА вот насчет интерфейса есть одна важная деталь - плохо совместимые параметры инициализации. Мы можем либо искусственно стандартизировать их, сделав объемлющий объект "набор параметров", либо предоставить объектам разбираться с ними на месте.такие параметры будет уместно передавать в фабрику при её создании прямо в DerivedClass, в качестве бонуса получим строгую типизацию.

softwarerВ постановке, как я ее понял изначально, проводится прямая связь между конкретным классом коллекции и конкретным классом элемента коллекции.ну обычно связь элемента с коллекцией выражается в том и только в том, что элемент содержится в коллекции. Если элемент явно зависит от коллекции – тут, да, согласен – фабрика не спасёт, придётся доинициализировать после отработки базового конструктора.

...

Рейтинг:

0 / 0

25.12.2006, 17:28

| Ответить | Цитировать | Написать

ООП

#34223480

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

maXmoхм… да, но не он у нас камень преткновения, а вызов метода на несконструированном объекте (в процессе его конструирования).
Хм. Мы же уже вроде разобрались, что идеологически такой подход не является априори плохим.

"Несконструированный объект" - это малоудачная абстракция. Технически она имеет определенное значение в C++ и только там. Практически же - она может быть и имела бы смысл, если бы после вызова new всегда и везде выходили полностью инициализированные объекты. Но это не так; мы обычно не хотим запихивать в конструктор необходимое количество параметров, мы хотим определенную свободу, поэтому в относительно сложных объектах между "окончанием начального конструирования" и "возможностью практического использования" выполняется еще уйма действий, "доинициализация". Вызов методов при этом допускается и активно осуществляется - а если так, почему собственно граница проведена именно так? Почему, с Вашей точки зрения, код

Код: plaintext

1.
2.
3.
4.
5.
6.

 class  Something {
  pubic Something() { ... }
   public  setSomeValue ( int  value) { ... }
}

Something s =  new  Something();
s.setSomeValue ( 1 );

является нормальным, а вот код

Код: plaintext

1.
2.
3.
4.
5.
6.

 class  Something {
   public  Something ( int  value) { ...; setSomeValue (value);}
   public  setSomeValue ( int  value) { ... }
}

Something s =  new  Something ( 1 );

Вы вдруг считаете плохим, подверженным ошибкам и вообще идеологической проблемой?

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

Скажем, в той постановке, которую я обрисовал, метод может быть сделан статическим [если я правильно употребляю терминологию - в дельфе это называется class method, метод, принадлежащий "классу в целом", а не конкретному экземпляру]. И какие ясно-какие-баги при этом удастся внести?

maXmoтакие параметры будет уместно передавать в фабрику при её создании прямо в DerivedClass, в качестве бонуса получим строгую типизацию.
К сожалению, получим мы кукиш, псевдострогую типизацию.

Терминологически, что есть строгая типизация: проверка компилятором соответствия передаваемого значения ожидаемому. Согласны? И тут следует ключевой момент: "ожидаемому" можно понимать как "формально ожидаемому", а можно как "фактически ожидаемому". Практически нам интересен второй вариант, а получаем мы первый.

Это легко проиллюстрировать следующим кодом:

Код: plaintext

1.
2.
3.

 procedure  DoSomething ( i : integer ) ;  begin  ...  end  ;

 begin  ... DoSomething ( '123.45' ) ; ....  end  ;
   (* Получим ошибку на этапе компиляции *)

Код: plaintext

1.
2.
3.
4.

 procedure  DoSomething ( i : variant ) ;  begin  ...  end  ;

 begin  ... DoSomething ( '123.45' ) ; ....  end  ;
   (* Формально строгая типизация есть, а на этапе выполнения получим ошибку.
     Может быть. В зависимости от настроек десятичного разделителя в системе *)

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

maXmo softwarerВ постановке, как я ее понял изначально, проводится прямая связь между конкретным классом коллекции и конкретным классом элемента коллекции.ну обычно связь элемента с коллекцией выражается в том и только в том, что элемент содержится в коллекции.
Обычно - может быть, хотя имхо это неверное утверждение. Скажем, если у меня есть коллекция сотрудников, вполне уместно иметь в ней методы "найти сотрудника по фамилии", "найти сотрудников отдела X" итп.

maXmoЕсли элемент явно зависит от коллекции – тут, да, согласен – фабрика не спасёт, придётся доинициализировать после отработки базового конструктора.
Не понял мысль.

...

Рейтинг:

0 / 0

25.12.2006, 18:21

| Ответить | Цитировать | Написать

ООП

#34227259

BrokenPot

Участник

Откуда: Киев

Сообщения: 1 364

Рейтинг: 0 / 0

Надоело? :)

А я с таким интересом читаю... :)

Аналогия моей задачи с мячами, насосами и ниппелями у меня плохо получилась... :) кто у меня насос, а кто - ниппель?

...

Рейтинг:

0 / 0

27.12.2006, 11:31

| Ответить | Цитировать | Написать

ООП

#34227948

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

27.12.2006, 14:13

| Ответить | Цитировать | Написать

ООП

#34228558

dejavew

Гость

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

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

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

...

Рейтинг:

0 / 0

27.12.2006, 16:51

| Ответить | Цитировать | Написать

ООП

#34228578

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

dejavewЗабавно, насколько я помню начало топика - речь не шла: ни о коллекциях, ни о наполнении их (коллекций) какими-либо элементами.
Попробуйте прочитать чуть дальше начала - потом постановка вопроса была уточнена. Если бы не это, до сих пор бы шел абсолютно бессмысленный треп в духе первых постов.

dejavewМяч (мячи) - это экземпляры BaseClass и DerivedClass (должны быть наполнены "газом");
Газ (газы) - внутренние члены BaseClass и DerivedClass
Газов в моей аналогии нет. Если Вы умеете считать, обнаружите, что описали четыре элемента, а мы до этого говорили только о трех.

dejavewПо-вашему, softwarer, получается, что - раз "ниппель" не нужен
Еще одно неверное утверждение, приписываемое мне, скорее всего в силу крайне невнимательного чтения, возможно в силу изначальной одиозности.

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

...

Рейтинг:

0 / 0

27.12.2006, 16:57

| Ответить | Цитировать | Написать

ООП

#34228715

dejavew

Гость

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

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

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

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

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

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

...

Рейтинг:

0 / 0

27.12.2006, 17:33

| Ответить | Цитировать | Написать

ООП

#34228766

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

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

dejavewОтсюда я делаю вывод о том, что автором "мячно-газово-насосной" аллегории являешься не ты,
Можешь, конечно, отсюда, а можешь посмотреть сообщение непосредственно перед цитируемым, написанным мной.

Я действительно не являюсь автором "мячно-газово-насосной" аналогии, я являюсь автором "мячно-ниппельно-насосной" аналогии. В цитируемом тобой письме maXmo добавил к газ, но далее он нигде не упоминался по одной простой причине: он несущественнен, не несет функции, интересной с точки зрения задачи.

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

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

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

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

Резюмируя: очередной представитель серого племени серых ников. К сожалению, ничего интересного.

...

Рейтинг:

0 / 0

27.12.2006, 17:52

| Ответить | Цитировать | Написать

ООП

#34228813

dejavew

Гость

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

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

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

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

...

Рейтинг:

0 / 0

27.12.2006, 18:08

| Ответить | Цитировать | Написать

ООП

#34228902

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

dejavewДа уж, трудно врубиться в то, что элемент коллекции оказывается для нее - "снаружи, отделимый и независимый"... или ты свой собственный русский язык изобрел?
Ты можешь вытащить элемент из коллекции и работать с ним? Можешь убрать из коллекции все его следы, по-прежнему при этом храня прямую ссылку на него и работая с ним? Значит, он отделим. Если дашь себе труд подумать, разберешься и с остальным, в рамках общепринятого русского языка.

dejavew softwarerочередной представитель серого племени серых ников...
Не суди и не судим будешь...
Склонность к банальностям не красит человека.

"Не судить" минимально вменяемый человек не может физически, поскольку это означает "не иметь собственного мнения".

"Не судим будешь" меня не интересует, обратная перспектива не пугает.

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

Машину логического вывода тебе стоит поднастроить. Я не процитировал твои слова потому, что не нашел в них чего-либо интересного и/или заслуживающего ответа.

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

...

Рейтинг:

0 / 0

27.12.2006, 18:47

| Ответить | Цитировать | Написать

ООП

#34229265

BrokenPot

Участник

Откуда: Киев

Сообщения: 1 364

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

28.12.2006, 00:11

| Ответить | Цитировать | Написать

ООП

#34229281

BrokenPot

Участник

Откуда: Киев

Сообщения: 1 364

Рейтинг: 0 / 0

Я действительно хотел поставить вопрос в общем виде, безотносительно к внутреннему содержанию конструкторов.

О коллекциях пришлось сказать просто для того, чтобы хоть как-то конкретизировать постановку задачи, что называется, для затравки. :) Если бы в конструкторах не заполнялись бы никакие коллекции, а осуществлялась бы какая-то другая деятельность, то вопрос все равно оставался бы актуальным.

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

Далее обсуждающие стали развивать тему, а заодно - и представленный мною пример, на свой лад. Такое обсуждение имеет полное право на существование, но имеет так же и весьма косвенное (уже теперь) отношение к поставленному мною вопросу.

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

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

Мое непонимание, надеюсь, будет простительным с вашей точки зрения, если примете во внимание, что я - начинающий ООП программер.

...

Рейтинг:

0 / 0

28.12.2006, 00:29

| Ответить | Цитировать | Написать

ООП

#34229824

dejavew

Гость

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

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

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

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

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

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

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

...

Рейтинг:

0 / 0

28.12.2006, 11:07

| Ответить | Цитировать | Написать

ООП

#34230672

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

dejavew Иногда люди не дают себе труда возражать на откровенную белиберду, т.к. им жалко тратить на это бесцельное занятие свое драгоценное время
И давно ты это выяснил? Или только после того, как я объяснил тебе, почему не отвечаю на каждую твою фразу?

dejavew Однако, мне все ж таки интересно как ты, как гигант мысли и великий настройщик машины логического вывода, сможешь убедительно "отчуждить" тип int от коллекции IList<int>, например?
"Смочь" я наверное не смогу, это уже давным-давно сделано без моего участия.

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

Пользовался ли ты когда-нибудь типом int вне коллекции IList<int>?

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

Если ответом на оба вопроса будет "нет" - ты прав, тип int неотчуждаем. Для тебя.

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

Что касается экземпляров - они могут быть помещены в контейнер и могут быть извлечены оттуда, они также вполне отчуждаемы. Чтобы ты понял, придется снова прибегнуть к аналогии - водитель вполне отчуждаем от машины. Он ни к чему внутри не приклеен, может открыть дверь, выйти и даже никогда не вернуться.

dejavew(и не заводи опять бодягу с притягиванием за уши конкретных экземпляров в конкретных ячейках коллекции,
Ага, то есть наполовину ты понял, теперь пытаешься передернуть к типам.

Итак, по-твоему, "тип int" является "неотчуждаемым от типа IList<int>". Теперь ты позиционируешься на этой чуши?

...

Рейтинг:

0 / 0

28.12.2006, 14:50

| Ответить | Цитировать | Написать

ООП

#34231279

dejavew

Гость

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

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

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

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

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

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

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

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

...

Рейтинг:

0 / 0

28.12.2006, 18:06

| Ответить | Цитировать | Написать

ООП

#34231684

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

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

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

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

dejavewприцепиться к формулировкам и добивать железо-бетонными "банальностями"
Хм. Такое впечатление, что ты считаешь меня обязанным помочь тебе опровергнуть и развенчать меня, и мое несогласие с такой политикой тебя обижает.

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

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

Фу, совсем скучно передергиваешь, словно по обязанности. Так, будто сказать нечего, а надо. Ухитряешься от изначальной задачи (положить в коллекцию наследника) перейти к задаче, где "слава БГ наследники невозможны".

Впрочем, возможно для тебя это новость - но правильный ответ таков: зависит от деталей реализации в конкретном случае. IList как понятие вроде бы есть только в .NET; в нем я некомпетентен и не могу ответить. Для дельфы ответом на аналогичный вопрос будет "да, без проблем".

...

Рейтинг:

0 / 0

28.12.2006, 23:41

| Ответить | Цитировать | Написать

ООП

#34232579

dejavew

Гость

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

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

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

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

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

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

...

Рейтинг:

0 / 0

29.12.2006, 13:01

| Ответить | Цитировать | Написать

ООП

#34232641

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

dejavewОчень удобная позиция - там где это выгодно прикинуться дурачком, не знающим и не желающим знать синтаксиса generic-ов в C#2.0,
Теперь понятно, почему ты вещаешь чушь вместо того, чтобы временами честно сказать "я этого не знаю" - для тебя это эквивалентно "выглядеть дурачком".

Не комплексуй. Как говаривал классик, "не стыдно не знать - стыдно не учиться". В частности, если для тебя возможности механизма сводятся к синтаксису - определенно, еще "учиться и учиться".

...

Рейтинг:

0 / 0

29.12.2006, 13:22

| Ответить | Цитировать | Написать

47 сообщений из 47, показаны все 2 страниц

все

Форумы / Программирование [игнор отключен] [закрыт для гостей] / ООП

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?all=1&fid=16&tid=1346350]:	0ms
get settings:	7ms
get forum list:	15ms
check forum access:	2ms
check topic access:	2ms
track hit:	145ms
get topic data:	8ms
get forum data:	2ms
get page messages:	80ms
get tp. blocked users:	1ms
others:	203ms

total:	465ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы