LINUX.ORG.RU
Форум — Development  

слишком много generic types

 , ,


0

1

запилил очередной проект и после уже понял, что меня как-то подворачивает от того что у меня огромное количество типов написано в виде SomeInterface<SomeType>. собственно, все как бы и не сказать что плохо, но очевидно, что это несколько снижает уровень абстракции везде по коду. собственно, вопрос: а может это хорошая практика дописывать новые типы, чтобы избежать через чур большего количества использования дженериков? может есть какое-то золотое правило? я собственно понимаю, что дженерики как раз для того, чтобы типы не росли кобминаторно, но мы же все-таки пишем конкретные типы. на ум приходит правило что-то типа: во-первых, если не нужен дженерик именно из-за переменной типа, и мы пишем SomeInterface<SomeType> как миниму дважды, то есть смысл заколбасить SomeTypeSomeInterface. во-вторых, если SomeInterface<SomeType> имеет взаимнооднозначное соответсвествиее с каким-то конкретным SomeTypeSomeInterface, то от дженирика лучше избавиться.

в общем, буду рад услышать ваше мнение.



Последнее исправление: yetanotherguy (всего исправлений: 1)
← Подскажите, пожалуйста, кроссплатформенное решение проблемы русского ввода и русского вывода на c++?
Ограничить доступ программы к каталогам →

Генерики вышли из функционального программирования. Там они известны как параметрический полиморфизм. Их действительно как-то пытаются использовать вместе с ООП... Может и есть польза от этого? Вот ты не знаешь, и я не знаю.

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)

Хотя вот в Ada 83 уже были генерики, но то было процедурное программирование с элементами объектного. Ну, вот, пользу-то, значит, нашли! Там ты вывод в файл не смог бы сделать без генериков, если правильно помню.

dave ★★★★★
()

Женерики лучше действительно в сыром виде не использовать, иначе потом начинает получаться поток сознания вида List<Pair<h_object,Tuple<Int,Int,Set<Int>>>>

Nastishka ★★★★★
()
Последнее исправление: Nastishka (всего исправлений: 1)

ну ладно, окей, давайте иначе попробуем.

вот есть у нас Handler<A> и есть у нас AHandler implements Handler<A> вопросов что использовать, когда нам надо что-то помимо Handler<A>, что есть в AHandler, нету. но что делать, если разницы нет? вроде бы как Handler<A> более общий, и мы туда сможем запихнуть какую-нибудь композицию/прокси/етц, но с другой стороны это же все можно запилить и под AHandler плюсы юзать AHandler: 1. понятно где лежит вся реализация(сразу вопрос, а что если этой конктретной реализации нет) 2. абстракиця: один айдишник лучше двух, тут думать нечего. минусы: пахнет горой кода в пределе. плюсы Handler<A>: собствнно общность, вроде бы как кода придеться меньше писать (а так ли это).

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

yetanotherguy
() автор топика
Ответ на: комментарий от Nastishka

Pair<h_object,Tuple<Int,Int,Set<Int>>>

В данном случае проблема не в дженериках, а в ДНК 5 неименованных полях.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от Nastishka

О, привет, давно тебя здесь не видел ) Как поживаешь? )

А по поводу List<Pair<h_object,Tuple<Int,Int,Set<Int>>>> в Скале, например, чтобы избежать такого есть чудное ключевое слово type, в C++ можно воспользоваться typedef.

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

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

До Type[+T] и Type[-T] там еще не додумались, это да (

LongLiveUbuntu ★★★★★
()

так че? нет мнений у лора чели? надо было спрашивать во вконтакте?

yetanotherguy
() автор топика

Юзай языки без дженериков. Чем меньше фич, тем меньше страданий по поводу «а что бы выбрать». Си и го хватит всем.

bread ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Подскажите, пожалуйста, кроссплатформенное решение проблемы русского ввода и русского вывода на c++?
Development
Ограничить доступ программы к каталогам →