Spreading a class to several file
Monkey Forums/Monkey Programming/Spreading a class to several file
| ||
| when im making a big class with lots of functions it is hard to program like that. so im forced to work not under a class just because of the mess. is there a way to spread a class on more then one file? |
| ||
| Nope. If your class is that big, you should refactor. |
| ||
| when you build a project and you dont want some vars to be accessed by other files. how can you enclose those vars without putting then into classes? |
| ||
Class Foo Private Field bar:Int Public Field test:String The variable bar can not be directly accessed outside the Foo class's module. |
| ||
| Sometimes you really do want one or two giant classes. I don't believe it's always wrong. C# has a feature in which you can split classes between files, and I guess you could do it with C/C++ too, though I never heard of it (except of course that most classes in C/C++ are in two files, a header and a source file). Monkey IDE does not help with giant classes of course! One refactoring option is to use inheritance. For example if you were creating an RPG, you might have a Creature class that handles moving around the dungeon, then a Monster class that extends Creature and has all the methods for combat etc., then a Player class that extends Monster and looks after inventory, character development and such. Each of the classes can call on base ('Super') class fields and methods, but the fields and methods relating to the different areas of responsibility will be in their own class. Also, while Monkey does not have an easy way of enforcing const access to public class fields, you can enforce it in your own code. It is much safer (IMO) to allow read access than write access, and more often than not that is all you want. (You can enforce it with properties, of course, but I don't really like those, seems like a lot of coding just to pretend you can break good coding practice. Maybe some day I will see the light regarding properties, but for now I leave them alone and even put in redundant brackets where they have been built in.) My coding standard for Monkey is that unless a method is written DoSomething( _foo:SomeClass ) where _foo has an underscore preceding the name, the method is not permitted to change foo. There is a similar rule for methods, which are supposed to be const unless they start with an underscore - though of course I have to live with New() and I don't enforce the rule for certain utility classes, or where I have noted that a field is to be considered mutable. |
| ||
| Giant classes are a bad idea IMO. As Gerry says, use small classes and inheritance. |
| ||
| For example if you were creating an RPG, you might have a Creature class that handles moving around the dungeon, then a Monster class that extends Creature and has all the methods for combat etc., then a Player class that extends Monster and looks after inventory, character development and such. What if you decide you want your monsters to have an inventory? Then you have to move the inventory code up to that class. Have a look at component-based design. It's one of the buzzwords at the moment. :) Check out the articles on this stackoverflow answer: http://stackoverflow.com/questions/1901251/component-based-game-engine-design |
| ||
| Have a look at component-based design. It's one of the buzzwords at the moment. :) And what a great link to promote Component-based design: My opinions after 2 years of experience with CBSE in games thought are that object-oriented programming is simply a dead-end. Why I switched from component-based game engine architecture to FRP. (functional reactive programming) LOL! |
| ||
| And what a great link to promote Component-based design: Yeah I saw that before I linked it, but I thought the only person who would notice would be you. :) |
| ||
| I agree that aggregation is also part of the strategy for shrinking classes. An Inventory class would probably be a good idea in the example, and increase your flexibility if you are unsure who is going to have an inventory. Aggregation of components is part of OO methodology IMO. |
| ||
| If I have a class that is more than a couple of screens long I will definitely refactor but I wouldn't get there in the first place. I tend to use short classes and larger managing scaffolds around them. |
   |