Войти
ФлеймФорумПрограммирование

Почему в ООП языках есть объявление подклассов, но нет объявления надклассов? (2 стр)

Страницы: 1 2 3 4 5 Следующая »
#15
21:18, 31 дек. 2015

Sbtrn. Devil
могу точно сказать что ты спрашиваешь тоже самое только в профиль (пытаешься разобраться)
..там пост и далее вниз по теме

Computer Navigation
Droid A4 T4 N3 - Izumrud Droid of Maze Dragon | Почему в ООП языках есть объявление подклассов, но нет объявления надклассов?

Sbtrn. Devil
твой метод который ты хочешь получить (даже тот идеал теоретический) в корне ущербен и не дееспособен ,
ибо в программе все что записано статично (все объекты со своим нутром) при изменении нужно переписывать весь код
и плюс невозможно работать со сторонними представления объектов : то есть гипер_болото / внешний_стоп_кран

Sbtrn. Devil
нужно : Объект_БД -> импорт в программу (БД программы) -> Конструктор Объекта по БД
другими словами компиляция-создание Объектов на_лету_программы также она называется Объектной Инициализацией
и все Объекты должны иметь ИД объекта с Корнями какими ты укажешь


#16
6:01, 1 янв. 2016

TarasB
> То есть это любому классу можно присобачить предка даже если он этого не хотел
> да это же мина.
Ты говоришь так, будто это что-то плохое, притом не конкретизируешь, чем именно. Но ведь это же не так. Даже тот факт, что самые мейнстримные и Ъ ооп-езыги насильно лепят всем классам предка Object, намекает, что подобный подход уже давно свербит сочинителям языков на интуитивном уровне.

> Идея имла бы смысл если бы новая база реально содержала лишь некоторые поля и
> методы наследника и не имела ничего своего.
Можно ограничить себя и этим, но от возможности добавлять свои методы с полями отказываться глупо. Более того скажу - противоестественно и нелогично отказываться от этой возможности. Раз ты вводишь в рассмотрение надкласс, значит, увидел в ранее несвязанных классах новый аспект, объединяющий их в рамках твоей ситуации. А новый аспект - новые свойства.
Та же read-only коллекция. Казалось бы, просто урезание возможностей read-write коллекции. Но не всё так просто. Тут же встаёт вопрос - а какой именно именно read-only? Он ведь бывает разный:
- коллекция вообще-то может измениться, просто её нельзя изменить с той стороны, куда её передали,
- коллекция не может изменяться вообще.
В качестве ответа на этот вопрос, всплывает новое свойство, описывающее характер толькочитаемости коллекции: то ли volatile, то ли mutable. Им и прирастает надкласс "read-only коллекция". А пока коллекция была полнофункциональной, об этом свойстве даже вопрос не мог встать: какой ещё характер толькочитаемости, если её заведомо можно менять?

Stone26
> У вас в семье говядину не едят, да?
И у мсье, конечно же, есть чем пояснить своё авторитетное мнение? Вот я, к примеру, предъявил пример ситуации, когда надкласс имеет смысл и необходимость. А мсье что имеет предъявить?

#17
14:10, 1 янв. 2016

Sbtrn. Devil
> - коллекция вообще-то может измениться,
> просто её нельзя изменить с той стороны, куда её передали
ну так это вроде как ближе в понимании : проще рассматривать package -и , создали нюкс_кнопку и вот
эта новая прямоугольная кнопка с надписью Sbtrn. Devil - можно инсталлировать пакаж в панель инструментария
компилятора (читать нутро программы) и даже пакаж может состоять из коллекции таких кнопок  , и вот настает момент
когда из прямоугольной кнопки получен наследник - круглая кнопка - теперь появилась необходимость из круглой кнопки
создать фундаментальный новый класс круглых кнопок путем их выделения в отдельный объект со всеми свойствами
которые были получены в длинной череде мутаций (пусть с десяток) до того пока появилась круглая кнопка как эволюция
.. нужно ли сохранять историю мутаций каким-то способом , если кнопка уже готова и цельна / самодостаточна ,
какие соединения могут быть оставлены / новые с предком и где тут собственно надкласс , может кнопка войдет в
новый объект как его часть и тогда нечто новое будет этим или скорее надкласс здесь придание свойству кнопки
тех свойств которых у нее не было за счет другого объекта - к примеру прозрачность которая была у Фоновой-Заставки
эта прозрачность крепиться отдельно к кнопке ,но возможно когда уже кнопка была выделена в отдельный объект
после тех предварительных этапов и тогда ее нужно снова выделять в Супер Новый Объект и тогда уж юзать / внедрять
..да тут поля не паханы

#18
14:56, 1 янв. 2016

Это что-то эпохальное. Надьестественное...
Диалог титанов геймдевру.
Диалог сердца и диалог духа.

#19
15:08, 1 янв. 2016

Метафизика ООП!

#20
16:39, 1 янв. 2016

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

#21
18:36, 1 янв. 2016

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

switch{ optional negative; optional zero; optional positive; } compare( int i, int k)
{
  if( i<k)
    return negative;
  if( i>k )
    return positive;
  return zero;
}

int switch{ divZero( int a) default { throw "divZero"}; } div( int a, int b)
{
  if( b==0 ) return void divZero(a);
  return a/b;
}



void main( void ) 
{
  compare( -1, 1 )
    negative -> print( "<" );
    zero -> printf( ">" );


  switch compare( -1, 1 ) {
    case negative:  print "<", value; break;
    case zero:  print ">", value; brea;
    default:  print "=";
  }

  int a = div( 5, 0 )
            divZero(int a) -> { printf( "divZero" ); result = 0; }

}

#22
12:57, 2 янв. 2016

susageP
> Объявление надклассов не надо. Нужно добавить возможность если класс реализует
> методы которые требует чисто виртуальный класс но его не наследует то тогда
> можно было кастовость к этому виртуальному классу.
Это и есть надклассы (несколько кастрированные, но тем не менее).
Впрочем, похожим образом работают интерфейсы в гугле Go(вно:) - там в классе не нужно явно объявлять, какие интерфейсы он имплементирует, это вычисляется компилятором по факту.

#23
13:56, 2 янв. 2016

susageP
> Еще нужно добавить ветвления в возвращающее значение метода чтобы наверняка
> отстрелить что то.
инам? буст:эни?

Прошло более 4 лет
#24
15:01, 17 янв. 2020

Внезапный ап.

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

abstract Amount
class Byte extends Amount
class Word extends Amount
То имея ссылку на абстрактный Amount мы не можем быть уверены что там либо Byte, либо Word, ведь кто-то мог отпочковать от Amount еще один класс.
И это плохо, у нас нет гарантий что мы сделали полный перебор всех возможных вариантов:
function (Amount amount) {
  if (amount instanceof Byte) ...
  else if (amount instanceof Word) ...
  else throw new Error(); // кто знает что еще там может быть?
}
Но если мы работаем с надклассами, то все проще:
class Byte
class Word
abstract Amount supers Byte, Word
Теперь мы явно ограничили что Amount это либо Byte, либо Word. Третьего не дано.
И это позволяет нам гарантировать, что если amount не Byte, то он 100% Word:
function (Amount amount) {
  if (amount instanceof Byte) ...
  else /* amount instanceof Word */ ...
}
Нерешенными остаются вопросы типа "может ли Amount быть и Byte, и Word одновременно?", но это уже другая история о неполноте декларативного подхода.

#25
15:15, 17 янв. 2020
Изображение
#26
17:36, 17 янв. 2020

Great V.
> у нас нет гарантий что мы сделали полный перебор всех возможных вариантов
Страуструп для этого придумал таблицу виртуальных вызовов. Наличие такой гарантии как раз является одним из основных преимуществ плюсов перед чистым си.

#27
20:26, 17 янв. 2020

Так и до торсионщины недолго

#28
23:45, 17 янв. 2020

Можно еще не только определять переменные какого то типа, но и какого типа есть какие то переменные. Тоже для полноты.

#29
23:45, 17 янв. 2020

Go еще не упомянули. Там же тоже есть интерфейсы. Только еще не требуют явного определения иерархии "суперирования". Объявили набор методов, у каких классов такие методы есть - те и годятся в такой интерфейс.

Страницы: 1 2 3 4 5 Следующая »
ФлеймФорумПрограммирование