LINUX.ORG.RU

Пустой класс. Ну вот совершенно пустой. Может стоит как-то иначе?

 , ,


0

3

Представьте себе ситуацию: есть ящики, в ящиках могут быть гвозди, бананы или коты. Очевидно что между гвоздями, бананами и котами общего ничего нет. А ящики стандартные и должны хранить указатель на содержимое.
Ну и что я делаю? Я создаю класс «содержимое», от которого будут наследоваться гвозди, бананы и коты.
Вот только эти классы настолько разные, что в базовый класс вообще нечего вынести.
Такой вот совершенно пустой класс, нужный лишь для приведения типов.
Сижу вот ржу.
Работать-то будет конечно, но может Чаушеску (или как там его) придумал какой-то более элегантный финт ушами? А то чувствую себя явистом с их любовью к иногда странной иерархии.

★★☆

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

Harald ★★★★★ ()
Ответ на: комментарий от ya-betmen

Ну что же я сделаю ежели они одинаковые? Да и начальнику склада пофиг что в ящиках — ящики с гвоздями и котами он будет складировать совершенно одинаковым образом.

Stahl ★★☆ ()
Ответ на: комментарий от Harald

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

Stahl ★★☆ ()
Ответ на: комментарий от Deleted

Коты без ящиков — неупорядоченная орущая масса.

Stahl ★★☆ ()

- Женщины Базовые классы нужны. Даже если сейчас они не нужны, уверяю вас, потом, будете бегать в поисках. (С)

ilovewindows ★★★★★ ()

Пустой класс. Ну вот совершенно пустой.

Это называется интерфейс. IPuttableInBox.

morse ★★★★★ ()

IUnknown. Добро пожаловать в COM

Gvidon ★★★★ ()

Почему ты хочешь хранить гвозди, бананы и котов в одном ящике? Сделай три разных ящика.

Stil ★★★★★ ()
Ответ на: комментарий от Stahl

Предлагаешь заставить базовый класс хранить данные о типе производного? Как вариант.

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

intelfx ★★★★★ ()
Ответ на: комментарий от Stahl

ящики с гвоздями и котами он будет складировать совершенно одинаковым образом

это точно? не будет такого, что ящик с котами нужно хранить при определенном температурном режиме, а ящик с гвоздями на специальном стеллаже с системой отгрузки FIFO?

system-root ★★★★★ ()
Ответ на: комментарий от Stil

Гм. Наверное потому что при дальнейшей транспортировке мне нет дела до содержимого ящиков. Они квадратные и тяжёлые. И храниться они будут на одном стеллаже вперемешку.

Stahl ★★☆ ()
Ответ на: комментарий от system-root

Нет, это специально обученные коты. Условия хранения всех ящиков будут одинаковые. Разница всплывёт лишь при распаковке ящиков: в зависимости от содержимого нужно будет использовать бананошелушитель, гвоздодёр или котоэкстрактор.

Stahl ★★☆ ()

про изобретение COM с его ЯНеинзвестный сказали?

anonymous ()
Ответ на: комментарий от Ceiling_QB

сериализовать в lua? мусьё знает толк

anonymous ()
Ответ на: комментарий от Stahl

зачем тогда вообще ящики? если котов завтра доставят в пакетах?
почему не сделать места хранение и номенклатуру, в зависимости от которой применять котоэкстрактор?
один пакет (0,5 куба) котов хранятся по адресу 46Б, при разукомплектации котоэкстракотором может стать 15 котов поштучно.
зачем ящики я не понимаю.

system-root ★★★★★ ()
Ответ на: комментарий от intelfx

А вот кстати будет повод поэкспериментировать — как-то не было повода потыкать в это палочкой.

Stahl ★★☆ ()
Ответ на: комментарий от system-root

Ящик нужен для указания адреса. Где адрес-то писать? Ладно ещё татуировку на коте, на каждый гвоздь маркировать это уж извините...

Stahl ★★☆ ()

boost::any или аналоги. Ну или variant, если всё-таки какие-то общие операции у котов и гвоздей есть или если хочется ограничить ящики котами и гвоздями на этапе компиляции.

Чем это лучше пустого класса? На практике например тем, что если понадобится хранить в ящиках собак из сторонней библиотеки, то не придётся писать обёртки.

caryoscelus ()
Ответ на: комментарий от Stahl

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

system-root ★★★★★ ()
Последнее исправление: system-root (всего исправлений: 1)
Ответ на: комментарий от Stahl
struct SomeBox
{
    enum {
        Nails,
        Bananas,
        Cats,
    } content;
    union {
        vector<Nail> nails;
        vector<Banana> bananas;
        vector<Cat> cats;
    };
};

P.S. пишу с кофеварки

Stil ★★★★★ ()

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

grondek ()

А по теме, передай выполнение этой задачи архитектору проекта, это в его компетенции

Harald ★★★★★ ()
Ответ на: комментарий от ckotinko

У вас злой надсмотрщик не позволяет смеяться на рабочем месте?:)

Stahl ★★☆ ()

а вообще, есть же варианты типа COM.

например ящик - интерфейс. вот как я делаю:

есть центральная библиотека core, которая дает классы ICore и IPlugin. Она же грузит другие библиотеки и добывает из них QObjectы, которые должны дать интерфейс IPlugin, которому будет дан init, а на удалении еще что нибудь. Есть еще куча интерфейсов, которые каждый плагин может отдавать как сам через метод, так и через прямой каст.

вот пример как есть коробки. а внутри что положили.

ckotinko ☆☆☆ ()
Ответ на: комментарий от Stahl

Нет ) Наши коты с гвоздями помещаются в ящики без проблем )

grondek ()

В нормальном языке это можно было бы написать, например, так:

data Boxed = BoxedCat Cat
           | BoxedNail Nail
           | BoxedBanana Banana

myList :: [Boxed]
myList = [BoxedCat myCat, BoxedBanana myBanana]
Там, где алгебраических типов на уровне языка нет, на помощь приходят решения вроде boost::variant (который метит в std) или самописного маркированного юниона.

С другой стороны, если у всех перечисленных сущностей есть размер/вес, то почему бы это не выразить в интерфейсе, который они реализуют?

Softwayer ★★ ()
Ответ на: комментарий от Stahl

Я заказчик, менеджер, архитектор и исполнитель. Как захочу так и сделаю.

так бы сразу сказал, что это не склад. а то я принялся чинить тебе бизнес-процессы

system-root ★★★★★ ()
Ответ на: комментарий от system-root

Это же ЛОР. Тут надо на кошках всё показывать иначе прибегут хаскеллисты, набросают монад и убегут. Ни пользы ни удовольствия.
А так вот мне напомнили про RTTI с которым я не сталкивался и потому просто даже не вспомнил о нём.

Stahl ★★☆ ()
Ответ на: комментарий от Stahl

В принципе да. Есть. Не понял вопроса...

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

anonymous ()
Ответ на: комментарий от anonymous

Моё время дёшево. Я не столько хотел спросить, сколько рассказать маленький ЖЖ-анекдот и выслушать какие-то нюансы. Вот мне напомнили про RTTI. Дискуссия оказалась не бесполезной.

Stahl ★★☆ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.