Search Results

Search found 6 results on 1 pages for 'panzercrisis'.

Page 1/1 | 1 

• Matching the superclass's constructor's parameter list, is treating a null default value as a non-null value within a constructor a violation of LSP?

  - by Panzercrisis

  I kind of ran into this when messing around with FlashPunk, and I'm going to use it as an example. Essentially the main sprite class is pretty much class Entity. Entity's constructor has four parameters, each with a default value. One of them is graphic, whose default value is null. Entity is designed to be inherited from, with many such subclasses providing their own graphic within their own internal workings. Normally these subclasses would not have graphic in their constructor's parameter lists, but would simply pick something internally and go with it. However I was looking into possibly still adhering to the Liskov Substitution Principal. Which led me to the following example: package com.blank.graphics { import net.flashpunk.*; import net.flashpunk.graphics.Image; public class SpaceGraphic extends Entity { [Embed(source = "../../../../../../assets/spaces/blank.png")] private const BLANK_SPACE:Class; public function SpaceGraphic(x:Number = 0, y:Number = 0, graphic:Graphic = null, mask:Mask = null) { super(x, y, graphic, mask); if (!graphic) { this.graphic = new Image(BLANK_SPACE); } } } } Alright, so now there's a parameter list in the constructor that perfectly matches the one in the super class's constructor. But if the default value for graphic is used, it'll exhibit two different behaviors, depending on whether you're using the subclass or the superclass. In the superclass, there won't be a graphic, but in the subclass, it'll choose the default graphic. Is this a violation of the Liskov Substitution Principal? Does the fact that subclasses are almost intended to use different parameter lists have any bearing on this? Would minimizing the parameter list violate it in a case like this? Thanks.

  Read the article

• Is creating a separate pool for each individual image created from a png appropriate?

  - by Panzercrisis

  I'm still possibly a little green about object-pooling, and I want to make sure something like this is a sound design pattern before really embarking upon it. Take the following code (which uses the Starling framework in ActionScript 3): [Embed(source = "/../assets/images/game/misc/red_door.png")] private const RED_DOOR:Class; private const RED_DOOR_TEXTURE:Texture = Texture.fromBitmap(new RED_DOOR()); private const m_vRedDoorPool:Vector.<Image> = new Vector.<Image>(50, true); . . . public function produceRedDoor():Image { // get a Red Door image } public function retireRedDoor(pImage:Image):void { // retire a Red Door Image } Except that there are four colors: red, green, blue, and yellow. So now we have a separate pool for each color, a separate produce function for each color, and a separate retire function for each color. Additionally there are several items in the game that follow this 4-color pattern, so for each of them, we have four pools, four produce functions, and four retire functions. There are more colors involved in the images themselves than just their predominant one, so trying to throw all the doors, for instance, in a single pool, and then changing their color properties around isn't going to work. Also the nonexistence of the static keyword is due to its slowness in AS3. Is this the right way to do things?

  Read the article

• Is creating a separate pool for each individual png image in the same class appropriate?

  - by Panzercrisis

  I'm still possibly a little green about object-pooling, and I want to make sure something like this is a sound design pattern before really embarking upon it. Take the following code (which uses the Starling framework in ActionScript 3): [Embed(source = "/../assets/images/game/misc/red_door.png")] private const RED_DOOR:Class; private const RED_DOOR_TEXTURE:Texture = Texture.fromBitmap(new RED_DOOR()); private const m_vRedDoorPool:Vector.<Image> = new Vector.<Image>(50, true); . . . public function produceRedDoor():Image { // get a Red Door image } public function retireRedDoor(pImage:Image):void { // retire a Red Door Image } Except that there are four colors: red, green, blue, and yellow. So now we have a separate pool for each color, a separate produce function for each color, and a separate retire function for each color. Additionally there are several items in the game that follow this 4-color pattern, so for each of them, we have four pools, four produce functions, and four retire functions. There are more colors involved in the images themselves than just their predominant one, so trying to throw all the doors, for instance, in a single pool, and then changing their color properties around isn't going to work. Also the nonexistence of the static keyword is due to its slowness in AS3. Is this the right way to do things?

  Read the article

• Are trivial protected getters blatant overkill?

  - by Panzercrisis

  Something I really have not thought about before (AS3 syntax): private var m_obj:Object; protected function get obj():Object { return m_obj; } private var m_str:String; protected function get str():String { return m_str; } At least subclasses won't be able to set m_obj or m_str (though they could still modify m_obj). Is this just blatant overkill? I am not talking about doing this as opposed to making them public. I am talking about doing this instead of just making the variables themselves protected. Like this: protected var m_obj:Object; //more accessible than a private variable with a protected getter protected var m_str:String; //more accessible than a private variable with a protected getter

  Read the article

• Should package structure closely resemble class hierarchy?

  - by Panzercrisis

  Pretty simple question. Should package structure closely resemble class hierarchy? If so, how closely? Why or why not? For instance, let's say you've got class A and class B, plus class AFactory and class BFactory. You put class A and class B in the package com.something.elements, and you put AFactory and BFactory in com.something.elements.factories. AFactory and BFactory would be further down the hierarchy package-wise, but they'd be further up class-wise. Is this sort of thing a good idea or a bad idea?

  Read the article

• When do you say "near ID" / "far ID" when using RTMFP in ActionScript 3?

  - by Panzercrisis

  I've been using RTMFP streaming for around a year in ActionScript 3, and I pretty much know the difference between a near ID and far ID. The near ID is your peer ID, and the far ID is the other guy's peer ID. The problem I'm having is that, to my knowledge, choosing whether to use one term or the other in a given sentence is a little like choosing whether to say "go" or "come". In English, "go" and "come" have opposite meanings, but ironically, they can still be used almost interchangeably. It's because whether you're going or coming is so heavily dependent on perspective, as opposed to anything concrete. Is the choice of words between "near ID" and "far ID" just as ambiguous, or is there some sort of method to the madness? Thanks!

  Read the article

1