OO Programming
BlitzMax Forums/BlitzMax Beginners Area/OO Programming
| ||
I've been hearing modular design..not sure what that means..i hear independs being used too. So here's my questions
Type 2Dpoint
Field X#,Y#
End Type
Type 2DPivot
Field P:2DPoint 'position
Field V:2DPoint 'vectors
Field N:2DPoint 'unit circle
Method New()
P = New 2DPoint
V = New 2DPoint
N = New 2DPoint
End Method
Method Delete()
P = null
V = null
N = Null
End Method
End Type
is there anything bad with using objects in objects? Do they mean you shouldn't have to depend on other objects that say you import from another source file? |
| ||
| No thats probper use of objects. Thats one of the good things, you can encapsulate subproperties to their own class with its own functionality (like .add .substract and others that might be usefull for 2D points in this example) |
| ||
| with modular *I* would mean: Complete self-contained autonome objects that could be replaced by a similar object made by another coder, as long as the fields/methods act the same.. I'd also skip anything remotely global, everything should be local in the object.. I always compare it with a modular synthesizer (those huge monsters with wires all over the place), each part (filter, oscillator etc.) works purely by itself, it doesn't know and doesn't need to know IF there are other objects and what they do. BMax's eventhooks/emitevents are the perfect aid to do this style o' coding. Beginner-programmers will notice that they probably can't just replace code or delete it without messing-up the project, that's not very modular then.. :P Naturally it also means that only including what you *need* results in a smaller file (find Framework assistant) but that's just something convenient for your .exe, doesn't say much about the style of programming. |
| ||
| is there anything bad with using objects in objects? Nope, just make sure you keep the coupling as low as possible, and the coherency as high as possible (so that changes will have a minimal effect on your existing code). Personaly, unless you have some methods to add to your 2Dpoint Type I there isn't much point in using it. I'd also skip anything remotely global, everything should be local in the object.. I disagree. There are quite a few cases (Singleton pattern for instance) where static references are absolutely nessecary. |
| ||
| This might sound silly, but i'm not 100% getting your point. Actually might be but in different words..so i'm searching to see how your statement differs from my thoughts. You have objects..say foundation objects. Points, Matrix(does the CPU do matrix calcs faster than a graphics card? GL has it built in but i often see software handle matrixs. You can always push the stack, do your calcs, load them then pop it back). A point object shouldn't care about a matrix object? Or You have Entity which cares only about what's inside it? Are you saying Entity shouldn't need another Object not encaps in itself? |
| ||
| I disagree. There are quite a few cases (Singleton pattern for instance) where static references are absolutely nessecary. But I guess you know what I mean, right? To avoid chaos somewhere because some variablename was already used. So, that singleton pattern might be an exception together with another handful o' thingies .. What I meant is: if you create for example a mapeditor, then don't create a few functions to update the map and do the events while all the map-variables (width/height/x/y/tileimages/eventstates/etc.) are just globals floating around everywhere. |
| ||
@Duck they'll still be a purpose. For an automation updater system i'm going to make. You just has the 2dPoint and have an array of functions that requires 2dPoint and makes ArrayI[] and ArrayF#[] optional. The object(2DPointAutomator) will have a 1D array for procedures and a 2D array for args. THe first dimension is for creating a parallel with the currenct Procedure and the second array is for the passed functions args.
Function ShakeXY( 2Dpoint, I[]=Null, F[]=Null ) 'Sees if I or F is not null then uses it for calcs.
Functoin ShiftXY( 2Dpoint, I[]=Null, F[]=Null )
2dAutomator.SetPoint( Camera.pivot.p )
' FunctPoint, I[], F[]
2dAutomator.AddProcedure( ShakeXY, [-2,2,-2,2], Null )
2dAutomator.AddProcedure( ShiftXY, [1,2], Null )
'Some where else code where it is Always called
2dAutomator.Update()
Method UPdate()
For I = 0 to funProcedure.length - 1
funProcedure[i](2DPoint, I[I][], F[I][] )
Next
End MEthod
That's just the rough idea of the system..there's alot more control..auto killing and such. But i'm just showing you why something like that could be useful. |
   |