4 ms·

I've been working on leaving OO recently. This is my current API. No deep nested hierarchies of classes anymore! self.player.addComponent(Controller()) sel

by seivan 12y ago

I've been working on leaving OO recently. This is my current API. No deep nested hierarchies of classes anymore! self.player.addComponent(Controller()) self.player.addComponent(Shooter()) self.player.addComponent(Jumper()) self.player.addComponent(Life()) self.player.addComponent(CharacterPhysics()) People who generally code applications could learn a lot from game developers and game engines. I took inspiration from Stencil and HaXe (but using Swift and SpriteKit) http://www.stencyl.com http://www.stencyl.com

jschwartzi 12y ago
That's an excellent use of Composition. Most people think inheritance hierarchies are necessary for OO, but composition/aggregation is a much better way to do things. A lot of the complaints I've read about OO center around people doing stuff that they later determine they didn't need to do, and then being stuck with it because it's in the middle of an inheritance hierarchy. Modern OO design would center around decomposing each class in the inheritance hierarchy such that the decomposition produces small subsets of shared behavior, and then composing those together to create the actual object. As a bonus you can still produce run-time polymorphism without crawling an inheritance hierarchy. Composition in an OO system is very much like composition in mathematics. Two objects are combined to produce the desired behavior. A lot of people crap on the GOF book because the patterns in it are either obvious or useless, but reading it does teach you some useful concepts, and for many people it will be their first direct exposure to something other than inheritance. Composition/Aggregation are great takeaways from that text. As an example of a crappy inheritance hierarchy, a developer 20 years my senior had this four-layer inheritance hierarchy to represent 3 different data types. After he gave it to me I spent 15% of my time convincing him to let me eliminate half the classes he wrote. The worst part was that he was inheriting and then in the subclass he was writing functions that were semantically identical to superclass or cousin-class functions, but with different names. After I eliminated all that I was able to use templates to hide a lot of the mess. OO design should be done according to the YAGNI principle--You Aren't Going To Need It--and its corrolary--do it as soon as you need it.
- seivan 12y ago
  Hey, thanks! Yeah, that's the impression I get. The ability to add functionality to an object in small modules (Components/Behaviours) However this only works if there is a inherent structure and ability to use components. Most frameworks and libraries I have worked with don't really have that structure. For instance, SpriteKit (Apples 2d framework) lacks a structure for building components. So most SpriteKit examples tend to have deep hierarchies of class inheritance. If you'd want to take a look I wrote this https://github.com/seivan/SpriteKitComposition https://github.com/seivan/SpriteKitComposition Documentation is still lacking as I am playing around with function names but it has a test suites that demonstrates usage.

by seivan 12y ago

jschwartzi 12y ago

That's an excellent use of Composition. Most people think inheritance hierarchies are necessary for OO, but composition/aggregation is a much better way to do things. A lot of the complaints I've read about OO center around people doing stuff that they later determine they didn't need to do, and then being stuck with it because it's in the middle of an inheritance hierarchy. Modern OO design would center around decomposing each class in the inheritance hierarchy such that the decomposition produces small subsets of shared behavior, and then composing those together to create the actual object. As a bonus you can still produce run-time polymorphism without crawling an inheritance hierarchy. Composition in an OO system is very much like composition in mathematics. Two objects are combined to produce the desired behavior. A lot of people crap on the GOF book because the patterns in it are either obvious or useless, but reading it does teach you some useful concepts, and for many people it will be their first direct exposure to something other than inheritance. Composition/Aggregation are great takeaways from that text. As an example of a crappy inheritance hierarchy, a developer 20 years my senior had this four-layer inheritance hierarchy to represent 3 different data types. After he gave it to me I spent 15% of my time convincing him to let me eliminate half the classes he wrote. The worst part was that he was inheriting and then in the subclass he was writing functions that were semantically identical to superclass or cousin-class functions, but with different names. After I eliminated all that I was able to use templates to hide a lot of the mess. OO design should be done according to the YAGNI principle--You Aren't Going To Need It--and its corrolary--do it as soon as you need it.

seivan 12y ago
Hey, thanks! Yeah, that's the impression I get. The ability to add functionality to an object in small modules (Components/Behaviours) However this only works if there is a inherent structure and ability to use components. Most frameworks and libraries I have worked with don't really have that structure. For instance, SpriteKit (Apples 2d framework) lacks a structure for building components. So most SpriteKit examples tend to have deep hierarchies of class inheritance. If you'd want to take a look I wrote this https://github.com/seivan/SpriteKitComposition https://github.com/seivan/SpriteKitComposition Documentation is still lacking as I am playing around with function names but it has a test suites that demonstrates usage.