что-то я не понял, как они собираются тестировать штуки, завязанные на системные функции.
вот, например, время. или рандом. надо мне перевести время для своих ф-ций или подкрутить рандом, чтобы выдавал только нужные мне в тестах значения.
мне их что, снаружи передавать? а если вложенность очень большая? протягивать через всю цепочку вызовов тяжко.
NL>Вообще в двух словах не расскажешь, так что если есть что-то более специфическое спросить, то лучше так.
у меня вопрос общий. хочется понять, что используют и как. желательно на примерах, а не на синтетике.
на синтетике всё выглядит очень просто, т.к. там обернуть что-то получается легко. с ростом размеров приложения код этим обрастёт, что уже тяжело будет разобраться.
в остальном просто собираю материалы на почитать-поучиться.
спрошу про наболевшее в haskell: как сделать наследование или заменить его?
есть у меня, к примеру, Paratrooper
делаю я пушку, которая умеет рисоваться, стрелять и принимать команды управления. пушка, вертолёты и пульки хранятся в одном списке, чтобы их можно было между собой сортировать и отрисовывать.
в какой-то момент хочется сделать пушку, у которой два ствола, и стреляет она другими пульками. а потом пушку с двумя стволами и ракетницей, и стреляет это всё третьим видом пулек и ракетами.
в ООП это всё делается через переопределение методов отрисовки и обновления состояния. при этом через шаблонный метод у меня всё это доступно весьма прозрачно. и при этом я ещё могу обратиться к родительской реализации и не дублировать код. например, вызвать отрисовку первой пушки, а второй ствол нарисовать рядом в дочернем методе.
в хаскеле мне придётся каждый нужный мне метод реализовывать отдельно. и это приводит к огромному оверхеду.
что с этим можно сделать?
Здравствуйте, dmz, Вы писали:
dmz>Использовать тайпклассы и композицию
каждую ф-цию тайпкласса придётся переопределять в дочерних. это я уже пробовал.
ещё предлагали хранить ссылки на ф-ции и получить эдакую динамику, как в питоне. или сделать свою vtable.
F>>в хаскеле мне придётся каждый нужный мне метод реализовывать отдельно. и это приводит к огромному оверхеду. F>>что с этим можно сделать?
dmz>Использовать тайпклассы и композицию.
Но IRL, конечно же, выяснится что никакую пушку из двух пушек никто никогда не композирует для
рисования, и что спрайты с фазами или векторная модель отдельно — и для неё вообще неважно,
двухствольная это пушка или гатлинг, активные точки, которые как-то взаимодействуют — отдельно
и их изначально N штук, ракеты отдельно и так далее.
А все эти истории про наследование двухствольной пушки от одноствольной, кенгуру с ПЗРК,
наследование квадрата от прямоугольника или прямоугольника от квадрата — не более, чем
народные анекдоты и сказки дедушки Гради Буча.
dmz>>Использовать тайпклассы и композицию
F>каждую ф-цию тайпкласса придётся переопределять в дочерних. это я уже пробовал. F>ещё предлагали хранить ссылки на ф-ции и получить эдакую динамику, как в питоне. или сделать свою vtable.
Ну пытаться всё делать привычными инструментами в любом языке можно, но неконструктивно.
Так-то --- полиморфизм — есть, модульность --- есть. Проблем с декомпозицией задачи обычно не бывает,
а как сделать что-то конкретное --- надо смотреть на конкретный пример. История про пушку выглядит
надуманной.
Здравствуйте, dmz, Вы писали:
dmz>История про пушку выглядит надуманной.
вот сейчас было обидно ._.
это действительно так происходит.
три компонента: отрисовка, управление и разные порождаемые объекты, — вот из чего складываются все эти комбинации.
обычно меняется 2 из 3х.
dmz>>История про пушку выглядит надуманной.
F>вот сейчас было обидно ._.
Нет, ну правда — отрисовка двухствольной пушки как-то отличается
от одноствольной? Казалось бы, и то, и другое — либо спрайт, либо
векторная модель в том или ином виде.
Просто постановка до боли напомнила замшелые задачки для собеседований — типа кто от
кого наследует — квадрат от прямоугольника или наоборот. Или построить иерархию
наследования для геометрических фигур.
Определение похожего поведения для разных типов обычно решается
тайпклассами или явной диспетчеризацией (PM) или совмещением
обоих подходов.
Может, лучше какие-то кейсы привести? Так-то:
class Drawable a where
draw :: Canvas -> a -> Canvas
data GunOneBarrel = GunOneBarrel GunAttributes
instance Drawable GunOneBarrel where
draw _ (GunOneBarrel{..}) = undefined
data GunTwoBarrels = GunTwoBarrels GunAttributes
instance Drawable GunTwoBarrels where
draw _ (GunTwoBarrels{..}) = undefined
Здравствуйте, dmz, Вы писали:
dmz>Нет, ну правда — отрисовка двухствольной пушки как-то отличается dmz>от одноствольной? Казалось бы, и то, и другое — либо спрайт, либо dmz>векторная модель в том или ином виде.
одноствольная состоит из двух спрайтов(башни и ствола), а двуствольная из трёх.
при этом при наследовании можно вызвать родительский метод отрисовки и к нему добавить второй ствол.
в случае х-я родителя так не вызвать, придётся дублировать код.
можно завести себе поле "parent" и обращаться к нему, но в случае нескольких уровней потомков нельзя вызвать отрисовку, обратившись прозрачно "насквозь" через несколько родителей.
вот вызов методов далёких предков я и ищу.
dmz>Может, лучше какие-то кейсы привести? Так-то:
.
F>одноствольная состоит из двух спрайтов(башни и ствола), а двуствольная из трёх. F>при этом при наследовании можно вызвать родительский метод отрисовки и к нему добавить второй ствол. F>в случае х-я родителя так не вызвать, придётся дублировать код.
В случае хаскеля нет никакого "родителя". Если у нас стоит задача отрисовывать
конструкции, составленные из нескольких спрайтов, то можно этого достичь примерно
9000 разными способами.
Один из них, например — взять значение, и выдернуть из него все спрайты
которые и отрисовать скопом:
F>можно завести себе поле "parent" и обращаться к нему, но в случае нескольких уровней потомков нельзя вызвать отрисовку, обратившись прозрачно "насквозь" через несколько родителей.
F>вот вызов методов далёких предков я и ищу.
Алё, тут нету наследования. Какие еще предки. Это же хаскел. И заметим, много где нету,
но ничего, живут как-то. Алсо глубокие наследования вроде бы ```considered harmful```,
и как свидетель системы с глубокими цепочками наследования --- соглашусь.
Ну и вообще --- мне тут видится подвох. С каких это пор графические объекты в играх
композируют в коде из спрайтов? А не рисуют/моделируют/размечают в редакторе? Скорее
всего, IRL тут будет таки один спрайт, смоделированный в редакторе, и какая-то
метаинформация.
И редактировать число стволов у пушки, приделывать свистелки и т.п. можно будет вообще
не трогая код.
Здравствуйте, dmz, Вы писали:
dmz>Один из них, например — взять значение, и выдернуть из него все спрайты dmz>которые и отрисовать скопом:
у них есть порядок, заданный в коде.
а что с остальными 8999?
F>>можно завести себе поле "parent" и обращаться к нему, но в случае нескольких уровней потомков нельзя вызвать отрисовку, обратившись прозрачно "насквозь" через несколько родителей. F>>вот вызов методов далёких предков я и ищу dmz>Алё, тут нету наследования. Какие еще предки. Это же хаскел.
алё, ты всегда можешь объявить поле/метод со значением типа предка. чтобы потом к нему обращаться и вызывать ф-ции "базовых типов".
dmz>но ничего, живут как-то. Алсо глубокие наследования вроде бы ```considered harmful```, dmz>и как свидетель системы с глубокими цепочками наследования --- соглашусь.
проблема в том, что в х-е 2+ уровня — это уже `considered harmful`
судя по синтаксису
dmz>Ну и вообще --- мне тут видится подвох. С каких это пор графические объекты в играх dmz>композируют в коде из спрайтов? А не рисуют/моделируют/размечают в редакторе? Скорее dmz>всего, IRL тут будет таки один спрайт, смоделированный в редакторе, и какая-то dmz>метаинформация. dmz>И редактировать число стволов у пушки, приделывать свистелки и т.п. можно будет вообще dmz>не трогая код.
да, вариант с наследованием и ручной отрисовкой — это из старых джвижков
в современных порядочно EntityComponentSystem, где как раз как-то это размечается в редакторе с метаинфой и автоматической отрисовкой.
сферически это так, да. пока не посмотришь поближе :3 если есть решение через паттерны, то я тоже буду за него благодарен.
Здравствуйте, dmz, Вы писали:
dmz>Но IRL, конечно же, выяснится что никакую пушку из двух пушек никто никогда не композирует для dmz>рисования, и что спрайты с фазами или векторная модель отдельно — и для неё вообще неважно, dmz>двухствольная это пушка или гатлинг, активные точки, которые как-то взаимодействуют — отдельно dmz>и их изначально N штук, ракеты отдельно и так далее.
не, это всё реальные ситуации.
вот у меня сейчас, например, если игрушка уровня Героев3, где в зависимости от повешенного баффа меняется поведение.
и тут драма в том, что в коде это не предполагается. например, нельзя в зависимости от баффа отобрать у игрока ход и походить автоматически.
гейдев — это такая сфера, где механика может меняться раз в день, потому что ГД воспринимают всё внутреннее поведение, как некую магию. типа, вжжжух, и что-то случилось.
мой пример может выродиться такой случай, что игрок управляет одной пушкой, а вторая работает автоматически. сама выбирает цель и отакует. а может нет.
поэтому это очень жизненно. я с этим примером пристаю к хакселистам, и пока не нашёл решения.
dmz>А все эти истории про наследование двухствольной пушки от одноствольной, кенгуру с ПЗРК, dmz>наследование квадрата от прямоугольника или прямоугольника от квадрата — не более, чем dmz>народные анекдоты и сказки дедушки Гради Буча.
ладно, это мб слишком тяжело.
подскажи лучше по онтопику. знаешь ли книжки/мануалы по проектированию в ФП? мне интересно для развития.
может я чего-то не понимаю ещё.
dmz>>Один из них, например — взять значение, и выдернуть из него все спрайты dmz>>которые и отрисовать скопом:
F>у них есть порядок, заданный в коде. F>а что с остальными 8999?
Ну так задать порядок в типе, или выводимый из типа, очевидно.
F>алё, ты всегда можешь объявить поле/метод со значением типа предка. чтобы потом к нему обращаться и вызывать ф-ции "базовых типов".
Не очень понял — можешь код показать? Что есть предок, например. Тут есть только композиция.
Конечно, можно напилить что-то вроде:
data Grandpa = Grapnda {...}
data Father = Father { grandpa :: Grandpa, fatherData = ... }
data Son = Son { father = Father, sonData = ... }
-- и потом делать как-то так:
instance Drawable Son where
draw (s@Son{..}) canvas = do
draw (father son) -- будет и отрисовка для "предков", если инстанс для Father определен таким образом
-- отрисовка для Son
Но это калька с Java-style ООП и так обычно не делают. Я бы просто сделал так,
что бы каждый тип содержал коллецию своих спрайтов, и выдергивал бы эти спрайты
с их атрибутами через syb. Включая порядок, который тоже можно задать разными
способами.
data OneBarrelGun = OneBarrelGun { sprites :: [Sprite] }
-- тоже WTF, калька с Java
-- чего б нам просто не перечислить нужные спрайты и не тащить сюда
-- OneBarrelGun, если он нам не нужен на самом деле
data TwoBarrelGun = TwoBarrelGun { oneBarrel :: OneBarrelGun, twoBarrelSprites = [Sprite] }
...
instance Monoid Canvas where
...
-- Template Method!
-- на самом деле, просто функция, которая имеет дело
-- с типами, для которых есть реализации нужных тайпклассов
draw :: (MonadDraw m, Data a) => a -> Canvas -> m Canvas
draw a = do
let sprites = sortBy spriteOrder [ x | x@(Sprite{..}) <- universeBi a ]
return $ foldMap (renderSprite emptyCanvas) sprites
F>проблема в том, что в х-е 2+ уровня — это уже `considered harmful` F>судя по синтаксису
Ну в языке, где вообще нет никакого наследования --- надо полагать.
F>да, вариант с наследованием и ручной отрисовкой — это из старых джвижков F>в современных порядочно EntityComponentSystem, где как раз как-то это размечается в редакторе с метаинфой и автоматической отрисовкой. F>сферически это так, да. пока не посмотришь поближе :3 если есть решение через паттерны, то я тоже буду за него благодарен.
Ну вот, привёл несколько вариантов. Да, тут нет наследования, vtbl и объектов, как смеси кода и данных.
Если всё это хочется, то надо, очевидно, использовать язык, где оно есть, зачем тогда Haskell ?
И еще надо учесть, что тут код отдельно — данные отдельно. Поэтому "наследование" в смысле Java-style OOP
особого смысла не имеет.
Пока не вижу ничего тяжелого. Т.е обычный подход — написать, что бы работало,
а если стало плохо, то отрефакторить.
Тут рефакторинг работает, потому, что есть типы.
F>подскажи лучше по онтопику. знаешь ли книжки/мануалы по проектированию в ФП? мне интересно для развития. F>может я чего-то не понимаю ещё.
Книжку не знаю, но обычно тут работает KISS
Т.е всё, что ты хотел сделать, вроде бы делается тем или иным способом.
Если видишь, что это приводит к бойлерплейту — просто обобщаешь и рефакторишь.
Обычные книжки вроде Лармана или Фаулера тут вполне работают, по крайней мере я в них,
бывает, поглядываю, когда делаю что-то жирное энтерпрайзное. Процентов 5 из них применимо.
Вопросы про паттерны и книжку по проектированию периодически поднимаются, но проблема в том,
что для архитектуры уровня систем/сервисов — подходят обычные знания, как у всех, а для
микроархитектуры того уровня, где важны "объекты" и "классы" работают принципы KISS и JFGID.
Может, полезен будет Рэймонд с его Data-driven design. Потому что здесь во многом он.
Надо еще учесть, что язык уровнем повыше, в нем есть много интересного для уменьшения кодобазы,
типа Generic и SYB, поэтому система, которая будет большой на C++, тут будет всё еще маленькой
в плане LoC.
F>мой пример может выродиться такой случай, что игрок управляет одной пушкой, а вторая работает автоматически. сама выбирает цель и отакует. а может нет. F>поэтому это очень жизненно. я с этим примером пристаю к хакселистам, и пока не нашёл решения.
Может быть, потому, что пример слишком общий и расплывчатый, и его можно реализовать
9000 способами, которые зависят от выбранных подходов. И в общем виде трудно что-то сказать
при такой постановке задачи.
Например, вот "герой управляет vs сама собой управляет". Очевидно, что оно управляется
потоком событий. И какая-то реализация "пушки" реагирует на события от "героя". А какая-то нет.
Но, очевидно, если это реализуется на Си (брейнфаке), то и на хаскелле тоже.
Здравствуйте, dmz, Вы писали:
F>>алё, ты всегда можешь объявить поле/метод со значением типа предка. чтобы потом к нему обращаться и вызывать ф-ции "базовых типов". dmz>Не очень понял — можешь код показать? Что есть предок, например. Тут есть только композиция.
я про такой Extends:
data BaseObject = BaseObject { img :: Image.Sprite } deriving (Show)
class Extends a where
type BaseType a
super :: a -> BaseType a
data Gun = Gun { gunBase :: BaseObject, gunDamage :: Int} deriving (Show)
instance Extends Gun where
type BaseType Gun = BaseObject
super = gunBase
instance SceneObject.SceneObject Gun where
draw gun delta = do
Image.draw (img . super $ gun) delta
return ()
update gun = do {print "gun update"}
data Bullet = Bullet { bulletBase :: BaseObject, bulletDamage :: Int} deriving (Show)
instance Extends Bullet where
type BaseType Bullet = BaseObject
super = bulletBase
instance SceneObject.SceneObject Bullet where
draw bullet delta = do
Image.draw (img . super $ bullet) delta
return ()
update bullet = do {print "bullet update"}
data Bullet2 = Bullet2 { bullet2Base :: Bullet } deriving (Show)
instance Extends Bullet2 where
type BaseType Bullet2 = Bullet
super = bullet2Base
instance SceneObject.SceneObject Bullet2 where
draw bullet delta = do {print "bullet 2 render"}
update bullet = do { print "bullet 2 update and:"; SceneObject.update $ super bullet}
dmz>Но это калька с Java-style ООП и так обычно не делают. Я бы просто сделал так, dmz>что бы каждый тип содержал коллецию своих спрайтов, и выдергивал бы эти спрайты dmz>с их атрибутами через syb. Включая порядок, который тоже можно задать разными dmz>способами.
да, я понимаю. поэтому вопрос в том, как это сделать идеологически верно.
dmz>-- тоже WTF, калька с Java dmz>-- чего б нам просто не перечислить нужные спрайты и не тащить сюда dmz>-- OneBarrelGun, если он нам не нужен на самом деле
хочется реюзать поведение и данные. это основная мотивация.
если это можно сделать через композицию, то прекрасно. мне всё равно как организовывать данные и ф-ции, если это решает проблему.
я просто не вижу, как можно одновременно реюзать и то, и другое. только по отдельности. а по отдельности меня не устраивает.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
