Is it a good practice to complement internal Gideros classes?

Apollo14 · August 2019

Hi guys!
Is it a good practice to complement internal Gideros classes instead of using global functions?

For example like here:

function Sprite:ignoreTouchHandler(event)
	-- Simple handler to ignore touches on a sprite. This blocks touches
	-- from other objects below it.
	if self:hitTestPoint(event.touch.x, event.touch.y) then
		event:stopPropagation()
	end
end
 
function Sprite:ignoreMouseHandler(event)
	-- Simple handler to ignore mouse events on a sprite. This blocks mouse events
	-- from other objects below it.
	if self:hitTestPoint(event.x, event.y) then
		event:stopPropagation()
	end
end
 
function Sprite:ignoreTouches(event)
	-- Tell a sprite to ignore (and block) all mouse and touch events
	self:addEventListener(Event.MOUSE_DOWN, self.ignoreMouseHandler, self)
	self:addEventListener(Event.TOUCHES_BEGIN, self.ignoreTouchHandler, self)
end

Or here:

function TextField:sayPhrase(newPhraseString)
	local function addSymbol()
		for i=1, #newPhraseString do
			self:setText(utf8.sub(newPhraseString,1,i))
			Core.yield(0.02)
		end
	end
 
	Core.asyncCall(addSymbol)
end

Or it is better to create regular functions?

pie · August 2019

I think it all depends on what do you plan to do. You can also keep the base class as it is and make a class that inherits stuff from that to have additional functions:

function Balloon = Core.class(TextField)
function Ballon:sayphrase ()...

Forgive me i am on mobile

antix · August 2019

I think it's fine to compliment them how you are doing.

tetnic · August 2019

Technically you are doing what is called "extension" or "category" on some languages as obj-c and swift where you add behaviors directly to an existing class without use the inheritance mechanism.

You have another way to obtain the same, that is to create a direct subclass (Sprite in this case) by which each classes in your app (MyGameSprite, or TouchBlockingSprite, or even TouchBlockingSprite inheriting from MyGameSprite) will inherit wanted behavior.

Each of them have strengths and weaknesses.

The first represents a shortcut in the way you avoid the creation of a new class. It can be also useful if you want to change something "not complex" to an existing code.

I would prefer the second solution because gives you a greater level of flexibility, and responsibilities separation. What in fact if you need (to implement your behavior) to do an "override" of some existing behaviors of the superclass?

What if you need multiple objects do different things? Your risk is to finish with huge superclasses that does everything.

Obviously the choice depends on the size of your project, if it is relatively small the risk to lose control over your internal architecture is low.

Despite my English level I hope this could be useful to you-

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Is it a good practice to complement internal Gideros classes?

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Is it a good practice to complement internal Gideros classes?

Comments