Придумай хоть одно практическое применение тому наследованию, которое описано :) Абстрактные классы, виртуальные функции - ничего же таким образом не реализовать. А там, где реализовать, там аггрегированный родительский элемент в принципе не нужен, достаточно статического метода (глобальной функции). Тут какая-то подмена наследования mixin-ами, кмк.Цитата:
Сообщение от Vitamin
Аффтар всего лишь рассуждает, можно ли полностью отказаться от наследования имплементации в пользу агрегирования (имхо, можно и даже нужно! И да, читай замечания).Цитата:
Сообщение от Eltaron
Мысли шире. Назови наследование от абстрактного интерфейса имплементацией (ибо де-факто ничего, кроме описательной части не наследуется) и вполне сможешь избавиться.Цитата:
Сообщение от Eltaron
Пример дашь?Цитата:
Сообщение от Eltaron
НавскидкуЦитата:
Сообщение от Vitamin
переписывается в идеологии статьи какКод:public Base
{
virtual int GetSomething1() = 0;
virtual int GetSomething2() = 0;
virtual int GetSomething3() = 0;
virtual int GetSomething4() = 0;
void DoJob() { print((GetSomething1()+GetSomething2()+GetSomething3()+GetSomething4()) * 57.2418); }
}
public Child : Base
{
int GetSomething1() { return 90; }
int GetSomething2() { return 5; }
int GetSomething3() { return 17; }
int GetSomething4() { return 9; }
}
Я, наверное, слишком привередлив, но мне кажется, что это хрень какая-то. Если бы я хотел передавать в функцию указатель на каждую требующуюся ей функцию, я бы писал на хаскелле. И это ещё методы примитивные, с 0 параметров! Даже на си с его полиморфизмом через структуры указателей это всё было бы в разы лаконичней.Код:typedef int (*get_something)();
public Base
{
void DoJob(get_something param1, get_something param2, get_something param3, get_something param4)
{
print((param1() + param2() + param3() + param4()) * 57.2418);
}
}
public Child
{
Base* base;
Child(Base* base) { this.base = base; }
void DoJob() { base->DoJob(GetSomething1, GetSomething2, GetSomething3, GetSomething4) };
int GetSomething1() { return 90; }
int GetSomething2() { return 5; }
int GetSomething3() { return 17; }
int GetSomething4() { return 9; }
}
Потому статья и тянет скорее на теоретические измышления, чем на практическую ценность.
Нет. Посмотри внимательнее, чем отличаются просто функции (глобальные) и методы класса (не важно, виртуальные или нет).Цитата:
Сообщение от Eltaron
Неа. Hisoft Паскаль и ассемблер (Gens) фиговаты, не удобны. Особенно бесит нумерация строк. На их Паскале серьезного ничего не напишешь. Поэтому пишем свои компиляторы.Цитата:
Сообщение от Alex Rider
Не знаю как обстоит дело с Паскалем для Z80, а у GENS'а есть достаточно удобных последователей. Да и в любом случае, компилятор Паскаля для Z80 я понимаю, сам даже баловался. А вот компилятор C# для Z80 не пойму.Цитата:
Сообщение от Andrew771
PS Вернее, не так. Компилятор с C# для Z80 не поймут именно тут.
Да хотя бы его идея "а давайте сведём наследование к пролиморфизму", теоретически можно (что он в статье и показал), а вот практической пользы от этого - ноль, потому что писать много лишнего придётся.Цитата:
Сообщение от Vitamin
ООП вообще - не более чем удобство записи. Всё можно и на обычном С реализовать, но писать больше придётся: вместо интерфейса - указатель на структуру с двумя указателями (данные и таблица виртуальных функций), вместо наследования - агрегация родительской структуры в структуре наследника, вместо инкапсуляции - просто соглашение "не трогай это".
Ну конечно. Лучше лишнего написать, чем лишний раз подумать.Цитата:
Сообщение от b2m
ООП- это смена парадигмы с "есть данные, а есть функции для их обработки" на "есть объекты, отражающие предметную область и состоящие из данных и поведения". И пока не осознаешь этого, так и будешь писать "брутальный *****код, представляющий собой кровавый замес из процедурного C, недообъектного и недотипизированного C++" (С)Цитата:
Сообщение от b2m
Хех. Судя по твоим словам, аффтар открыл делегаты - основную парадигму яблопрограммирования на objc.Цитата:
Сообщение от Vitamin
Я так не говорил. Лучше вдумчиво писать, чем постоянно думать о том, как можно было бы написать. :) У лентяя всегда инструменты виноваты.Цитата:
Сообщение от Vitamin
Данные и поведение было и до придумывания ООП. А объектами лучше называть реально существующие вещи.Цитата:
Сообщение от Vitamin
В том, что программы с ошибками пишутся, чаще всего виноваты люди, а не парадигмы.Цитата:
Сообщение от Vitamin