On Tue, 7 Jun 2016 6:31 AM Rudi Hammad <[email protected]> wrote: > > > El lunes, 6 de junio de 2016, 15:46:10 (UTC+2), Marcus Ottosson escribió: >> >> > Nope, a class method take the class as first argument and is supposed >> to return an instance of said class >> >> Just so we don't confuse Rudi, a @classmethod is like a regular method, >> except that it doesn't have access to its instance. >> > > I just read what I wrote before : > > *"avoid creating having to create the object" .....*avoid create having > to create...oh my god, what does that even mean!! > > what I meant was that the advantage of classmethod is that you don´t have > to create the object, meaning that you can call it directly from the class. > Sorry about that. > > Going back to general OOP with an example cesar said, i know it looks I am > reapting myself but bear with me for one second > What about a class Limb() that has methods to creates armJoints(self), > legJoints(self), spines.They have all in common being limbs right? > Then I have a subclass MakeIkLimb(Limb) that has methods create > simpleIk(self), or a reversefootIk(self), etc.... and then another subclass > called CartoonFeatures(MakeIkLimb) that will take those existing iks and > perform more operations like makeStretchyIk(self) etc.. > > Then way I would use that is: > · If I am rigging a realistic character, I don´t want any cartoon > features so I would create the object >> realLimb = MakeIkLimb(); and then > doing something like realLimb.simpleIk() I would create the ik sistem > · If I am rigging a cartoon character, I would create the object >> > cartoonLimb = CartoonFeatures(); cartoonLimb.makeStretchy() > > To sum up, I going from generic to specific.If I want realistic I go for > the class that creates just an ik sistem. If I want cartoon I go for the > class that requieres the ik from her superclass, and operates one it. I > mean, I can´t make a stretchyIk if I don´t have an ik > In my previous codes, I had makeStretchyIk as an argument of the makeIk() > method. But separating them in classes makes it cleaner because if I > discover a new way of makeStretchyIk, I don´t have to mess with makeIk(), > so that is safe no matter what. > > Is that better? or am I still going over and over again about the same > thing I didn´t understand before >
No it's not really better. Because you haven't said that makeIk() behaves any different depending on the derived classes. You have only said that you add more methods. So basically you don't achieve real generic polymorphism here because you basically just have to pick the right concrete class always to have the methods you want to call. They are like method sets without any different behavior. Also you arent defining a "Limb" as a thing. You are defining a collection of Limb-related tasks. Consider this modification to your example... What if your Limb class was a base class that contained all the behaviours of a generic limb. It could tell you about its properties as a limb as well (number of joints, etc). Then you can make a cartoon limb and override various methods or set different properties that would make that Limb behave and report in a way a cartoon limb would. The idea is that it can reuse the generic standards of a limb and override other behaviours to specialise it. The same makeIk() would behave differently for a cartoon and be stretchy, as opposed to it adding a makeStretchy. Point being, I could blind fold you and hand you some random subclass of Limb and you could use the common interface to make and operate a limb without knowing it's concrete type. I should be able to hand you a list of mixed Limb subclass instances and they would all be useful through the base interface. And yea there are times when you need need to type check or duck type check and use the unique features of the derived classes as well. > ps: I just bought on cgcircuit intro to pymel to see If I get a better > understanding of OOP > > > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/42005abc-18d3-4f20-b375-7bf678327d7a%40googlegroups.com > <https://groups.google.com/d/msgid/python_inside_maya/42005abc-18d3-4f20-b375-7bf678327d7a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0mXAXQBgBTx%3D_2f%2BZbTFaDRKxMZ7E459yNdQ_QYo177Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
