0

I'm following this Python Design pattern, and there is something I don't understand about the initialization() function:

class ObjectFactory:

   """ Manages prototypes.
   Static factory, that encapsulates prototype
   initialization and then allows instatiation
   of the classes from these prototypes.
   """

   __type1Value1 = None
   __type1Value2 = None
   __type2Value1 = None
   __type2Value2 = None

   @staticmethod
   def initialize():
      ObjectFactory.__type1Value1 = Type1(1)
      ObjectFactory.__type1Value2 = Type1(2)
      ObjectFactory.__type2Value1 = Type2(1)
      ObjectFactory.__type2Value2 = Type2(2)

Why the init for the variables are using the name of the class (i.e. ObjectFactory.__type1Value1) and not using self (i.e. self.__type1Value1)? When I changed to self:

   def initialize(self):
      self.__type1Value1 = Type1(1)
      self.__type1Value2 = Type1(2)
      self.__type2Value1 = Type2(1)
      self.__type2Value2 = Type2(2)

I got error TypeError: initialize() missing 1 required positional argument: 'self'.

But in another example, using "self" worked:

class Geek: 

    # Variable defined inside the class. 
    inVar = 'inside_class'
    print("Inside_class2", inVar) 

    def access_method(self): 
        self.inVar="a"
        print("Inside_class3", self.inVar) 

uac = Geek() 
uac.access_method()

Output:

Inside_class2 inside_class
Inside_class3 a

What am I missing?

Yagel
  • 1,184
  • 2
  • 18
  • 41
  • Please update your question with your call to `initialize()` – quamrana Jul 08 '19 at 15:04
  • Possible duplicate of [Why do we use @staticmethod?](https://stackoverflow.com/questions/23508248/why-do-we-use-staticmethod) – Mike Scotty Jul 08 '19 at 15:05
  • 5
    Side note: in the linked design pattern, it would have probably been better to decorate the methods with ``@classmethod`` instead of ``@staticmethod`` to avoid typing the class name. You can read about there difference here: https://stackoverflow.com/questions/136097/what-is-the-difference-between-staticmethod-and-classmethod – Mike Scotty Jul 08 '19 at 15:08
  • 3
    Frankly speaking, that tutorial does not seem to teach typical Python patterns and conventions. – Klaus D. Jul 08 '19 at 15:10
  • 1
    This is one more useless tutorial written by someone that has obviously not much experience with the language. Actually the whole serie is just as bad - the part on "the iterator pattern" just shows one simple generator function without even any explanation :facepalm: – bruno desthuilliers Jul 08 '19 at 15:20
  • @KlausD. I am more doing reverse engineering than learning about DP :/ – Yagel Jul 08 '19 at 18:52
  • @brunodesthuilliers Do you have better tutorial to learn DP? My boss asked me to learn DP for python, but I have no experience with DP (with any language), do you have any advice? – Yagel Jul 08 '19 at 18:54
  • 1
    @aronot design patterns are mostly language independant. If you understand the pattern itself - it's principle and the problem it's supposed to solve - and know the language, the effective implementation is just a detail. The best text about design patterns (and possibly one of the best texts about OO design) is still the original: "Design Patterns - Elements of Reusable Object-Oriented Software" by Gamma, Helm, Johnson and Vlissides (aka "the GOF"). – bruno desthuilliers Jul 09 '19 at 07:29

1 Answers1

2

When looking up the value of an attribute, self.foo will fall back to type(self).foo (roughly speaking) if there is no instance attribute named foo.

When setting a value, though, self.foo will always update (or create, if necessary) an instance attribute. You have to explicitly refer to the class to modify a class attribute.

In your other example, self "worked" in the sense that you verified the value of the new instance attribute inVar of uac. The class attribute Geek.inVar remained unchanged.

chepner
  • 497,756
  • 71
  • 530
  • 681