Object-oriented programming
BlitzMax Forums/BlitzMax Programming/Object-oriented programming
| ||
| I come from Blitz3D , and truth from my point of view I do not see benefits in doing all this, I think I 'm writing more code that makes the application , it is well implemented ?, what advantages does the code when it is object oriented ? How to improve the writing in this case? |
| ||
| Procedural code - i.e. what you write in B3D - is built out of fixed calls to a set of program functions. You gather up your objects and you pass them into these functions, which do whatever they do to the objects to produce some result. The same code is always running at any given point in the program. Object-oriented code packages the implementation of functions inside the data objects they work on. It's built out of a set of requests to the objects to do certain things according to their own version of the functions. This means that the code that runs at a given point in the program can be different depending on which object is asked to perform an action. The advantage of this is that you can add functionality while keeping the code that uses that functionality generic. In your example, you have two main types: TMEstatica and TMAnim. Both of these need to be Deinit after use. Say you're deinit-ing everything after a level has finished: in B3D, you'd need to have two collections - one of the TMEstatica objects, one of the TMAnim objects - and run two separate loops, one which runs Deinit_TMEstatica and one which runs Deinit_TMAnim. In BlitzMax, you can have a single loop that can contain all of your level's TMalla objects, and asks them to Deinit in whatever manner is appropriate for that type. If you added a third main type, you'd need to explicitly add a third collection to your B3D program's level data, and a third loop to explicitly clean up that collection after it was done. In BlitzMax, you wouldn't need to change the level cleanup code at all (assuming this third type also falls under TMalla) - you could objects of that type to the same collection, the same loop would ask those objects to deinit themselves, and it would continue to work with far less maintenance. In the object-oriented version, the level code no longer needs to know so much about the types of data it handles - it doesn't need to know what exactly the types are, how many of them there are, or what exact functions need to be called - which is good, because it reduces maintenance when you need to make changes, reduces surface area for bugs, and cuts out a bunch of knowledge that isn't relevant to how a level should work anyway (it's none of a level's business which function is called to deinit a TMAnim - why should it know that?). Your level code becomes much more generic and can easily handle expansions, while the equivalent B3D code can't handle expansions at all (it always needs to be rewritten if there's a change in the data structures). Note that the first box you've posted above is not object-oriented. It isn't using this generic capability at all - it's calling TMestatica.Deinit directly on one TMEstatica instance. It doesn't do anything different from the B3D code (using the `object.method()` syntax to call functions has absolutely nothing to do with object-orientation). Your second box does provide the ability to write object-oriented code though, by creating an abstract interface (TMalla) that can be used to operate on objects of either type. |
| ||
| I hope Google translate makes something useful from that :-) |
| ||
| Thanks You Yasha It's code Objetc?
Type TCar
Field maxMotor:float = 250.0
field velMotor:float = 0.1
function:TCar Init()
local oCar:TCar = new TCar
Return oCar:TCar
End Function
Method RunCar()
self.vel:float = self.vel:float * 0.5
if ( self.vel:float > self.maxMotor:float) then
self.vel:float = self.maxMotor:float
print ("RUn RuN...")
end If
End Method
End Type
Local Car:TCar = TCar.Init()
if (xKeyDown( xKEY_W:int ) ) then
Car.RunCar() ' Car Run
end if
|
   |