Command pattern in Python

I continue with "x pattern in Python" series, the articles i posted here are not tutorials or some professional learning resource. I poste them here only for myself to rememer the things when i need them :) What is the command pattern and why wee need it ? Well imagine you have a class that controls some operations on files, writing , reading , closing , and maybe many more. In first sight i would complete that like this :

class FileOperator:

def operation1(self):
  pass

def operation2(self):
  pass

#snip snip snip ....

Well that implementation seems enough for now, but what if we want to supply a simple api to users like that

f = FileOperator()
f.process_command()

Well, with current implementation that doesnt seem to be possible, the current implementation is kind fo static and user has to know the internals of the FileOperator class. If the users want some extra functionality like undo or logging, it will not be very easy to be implemented. And every change that has to be done will effect the current client code which is not cool. Also user may want when call the process_command to execute multiple commands like write_to_file and read_contents and etc. What we will do is again the basic OOP remove the parts that can change in the future. We will remove the executer parts and wiill assing them when we need them. Ok when reading it doesnt seem so easy but the code is easier:

Here is my implementation of the Command Pattern : LINK

After that implementation you will able to do things like that :

def test_me_yo():
  """
  Lets see that one
  """
  tmp_file = open("some.txt","w")
  tmp_file.write("hehehe\n")
  tmp_file.close()

  #end of initial data
  #first lets read the contents of the stuff
  fe = FileEditor()
  fileman = FileMan("some.txt")
  fread = FileReadCommand(fileman)
  fwrite=FileWriteCommand(fileman)
  fe.set_command(fread)
  fe.process_command()

  #append some info to the end of it
  fe.set_command(fwrite)
  fe.process_command("add some text here")
  fe.set_command(fread)
  fe.process_command()

  #lets now go and create an command manager
  cm = CommanManager()
  cm.add_commanders(fwrite,fread)
  fe.set_command(cm)

  fe.process_command("\n Add another sting here ")
  print "First undo :"
  fe.undo_process()
  print "Second undo :"
  fe.undo_process()
  print "Thirrd undo :"
  fe.undo_process()

Well it is pretty pluggable design you can combine the commands you like do "undo" all the magic you need. What i learned from Design Patterns is they are based on the same principle "remove the parts that will change in the future" ,separating the concerns is very important ...

Template Design Pattern

The next step in DP land is Template Design Pattern, well what is it ? As far as i understood there is nothing special and new under the hood. You have an abstract class with methods to be overriden by its sunclasses. The main difefrence is you have a one or more template methods which draw the flow of the things. A simple example maybe :

class MainClass(object):

 def operation1(self):
   #do stuff

 def operation2(self):
   #do stuff

 def __template_method(self):
   self.operation1()
   self.operation2()

What we did here is to supply an API for users to override the operation1 and operation2 but we want to control the overflow by template_method, if you want more extendible structure you may also make it public. Well i know that pattern i have used it in lots of places but didnt know its name :) The new thing i learned from Head First is the hook methods , you make them optional for the client code. For example:

class MainClass(object):

 def operation1(self):
   #do stuff

 def operation2(self):
   #do stuff

 def hook(self):
   pass

 def do_you_want_hook(self):
   return True

 def __template_method(self):
   self.operation1()
   self.operation2()
   if self.do_you_want_hook():
     hook()

Ok the difference is if user wants something extra to be executed he/she can override hook and do the extra stuf that is needed there,otherwise that method will not be invoked (well it will be but nothing will happen).
That is all for the template pattern, we know you,you are not new here :)

Factory Pattern in Python

Our next step in DP is object factories. Creating objects with if else clauses sometimes may not be very flexible for our programs. Some of the objects may neeed more complex and long initializations other maybe simple etc. Because of that it is cooler to have some methods or some classes that give you the instance you need. For exmple think about a client program which needs a slash directory or file manager. If you're trying to have your program platform independent you should have different versions for Windows and Linux based machines. Therefore when you client is initializing the File manager it should everytime do

 if linux:
   do sth
 else:
   do another

But for a framework that is not very flexible and when some code of FileManager changes (some code of initialization) you should change your client code which is not cool. It would be better if you have some class that gives you the instance you need, in our example FilemanagerFactory.get_instance() so client code will not care about the platform and other annoying stuf it will just get the instance it needs. Yep that is factory pattern ...
To demonstrate the factory thing i wrote a simple example that is responsible for creating Validators, if you have a string you get a string validator if you have an integer you have integer valiator and etc . Here is the link: LINK

To test the code you need sth like that :

from pyalgorithm.dp.factory import *

def test_facto():
   my_value = "Some_strrrrrrrrr"
   factory = ValidatorFactory()
   validator = factory.create(my_value)
   print validator.validate()

   my_value = 11
   validator = factory.create(my_value)
   print validator.validate()

   my_value = 11.12
   validator = factory.create(my_value)
   if not validator:
       print "No object created ..."

Well that is all, factory pattern may not be very important for little projects but if you have to initialize lots of classes it maybe wisw to have some class to do that for you.

Singleton Pattern in Python

The Singleton actually is not something very different or new invention. The purpose of it is to have only a single instance of some class so you can have a global point of access which is cool. For now i think i can use it for configuration manager classes, some cool loggers and some context variables. Maybe i will find more of em. The Singleton pattern is a little bit different from one that is in Java. In Java to make a singleton you have to make your constructor private and have some static method to do the instance initialization. In python what you have todo is override the __new__ method of the Singleton candidate. There are lots of examples on the net related with that topic so you can search one before use mine. Actually mine is not written or thought by me i found it also (from aspn CookBook site) :)

Here is the first version i found and think is good : LINK
As you will see there is some time and sleep things in it , i put em there to test what happens when some threaded classes use it. And as you may imagine some of the threads got different references of that Class. Here is the Thread i used :

from threading import *
import time
import thread

class ThreadSingleton(Thread):
    """
    A simple thread to work on that
    """
    def __init__(self,id):
        Thread.__init__(self)
        self.id = id

    def run(self):
        """
        Here initialize the singleton
        """
        self.s=Singleton()

        print "Im thread %d and %d"%(self.id,id(self.s))
        time.sleep(2)

    def get_singleton(self):
        return id(self.s)

Here is the code that tests it :

def singleton(t="threaded"):
    for j in range(100):
        threads = []
        for i in range(10):
            if t!="threaded":
                threads.append(ThreadSingleton(i))
            else:
                threads.append(RealThreadedSingleton(i))

        for i in threads:
            i.start()

        for i in threads:
            i.join()

        print "The final ids are :"
        t0 = threads[0]

        for i in threads:
            assert t0.get_singleton() ==  i.get_singleton()

        t0.s.destroy()


        if j%10 == 0:
            print "************** %d COMPLETED **********"%j

After those tests i got some Assertion Errors because some of the threads got different references of the object. What we know from here is that our Singleton is not thread-safe and we should fix it. Here is the threaded version of the Singleton LINK :

To test that new verison i nedded some new ThreadClass to call the new created Singleton :

class RealThreadedSingleton(ThreadSingleton):

    def run(self):
        """
        Here initialize the singleton
        """
        self.s=ThSingleton()

        print "Im thread %d and %d"%(self.id,id(self.s))
        time.sleep(2)

After final changes i run the tests 1000 times and didnt have any problems. Why we should bother to have Singleton threa-safe , because i'm going to use it in some frameworks that uses threads heavily, so icant be sure when that one will be called. To conclude, when write some cool classes always should think the posibility of theraded usages.

Decorator Pattern in Python

Our next step in DP is Decorator pattern, as u know Python also has some decorator options you can apply to your programs by @ sign. But if you want to apply decoration to classes in object level you have to change the stuff a little bit. I always thought that Java's IO library is very confusing, you create a FileInput class then you put it in a BufferReader and etc. When i read the Decorator chapter in Head First i realized that the Java IO API is using that pattern there. Well why do you need decorator pattern? Lets go from IO API example :
1. You have a normal reader
2. You need a reader that converts the input to lowercase, so what you do is create a new UpperReader
3. You need now a reader that converts input to a sha1 sum , what you do is create a Sha1Reader
4. You need a reader that converts input to uppercase sha1sum , what you do is create a Sha1UpperReader
5. The 4. item can be removed if you used the decorator pattern

Shortly, decorator pattern wraps an object and change its flow before or after the target operation. For the example above you can change the incoming input or process it to sth else.

Here is the implementation i wrote in Python and put on my personal github repo : LINK

A sample usage of above can be like that :

1. def deco():


2. from pyalgorithm.dp.decorator import *


3. 
   


4. print "The normal file reader content"


5. n = NormalFileReader("some.txt")


6. print n.read_content()


7. 
   


8. print "Sha1 sum of the read info"


9. sh =DecoratoSha1Reader(


10. NormalFileReader("some.txt")


11. )


12. print sh.read_content()


13. 
    


14. print "Sha1 sum but with upper cases"


15. up = DecoratoUpperFileReader(


16. DecoratoSha1Reader(


17. NormalFileReader("some.txt")


18. )


19. )


20. 
    


21. print up.read_content()

The output is sth like that:

The normal file reader content
Hey im the content!!!

Sha1 sum of the read info
5fd77bd8e4f80ec432c71a09033a7ef51de60448
Sha1 sum but with upper cases
5FD77BD8E4F80EC432C71A09033A7EF51DE60448

Well, it is the end of the today's pattern "decorator man". The post will be a good reference for me when forget the things :)

Observer Pattern in Python

Well here are the first things i got from "Head First Design Patterns" book :) I was working on a big web project and have also some small open source projects i try to finish. I stoppped codding on that projects immediately after read the first chapter of the book :) I realized that have big gaps in my programming skills about patterns. What i know now is :

- Knowing OO principles and rules doesnt make u a OO guru.
- Inheritance is not the best way of code reuse.
- Inherit the static parts and use composition for things that can change in the future.
- Less dependency between classes is alway better.

Will add to those more in the future i think.
Ok lets go back to the title of that entry. Sometimes we need to send some notifications to other classes from a specific class. What i would do before knowing the observer pattern would be sth like that. I would define a notifier() method and will call the classes i want to notify :

1. def notify(self):


2.    classA.update(args)


3.    classB.update(args)


4.    classC.update(args)


5.  

Ok it seems good for now but wat happens if you want to notify the classes D and E in the future u have to add them to the list above. That means altering the existing code which may not be a good idea. Ok now the classB doesnt want anymore to be notified , so what happens now ? It is very clear that the structure above is not the best for that situation. What we need is a dynamic srtucture which will allow us to add and remove new observers during the runtime without altering the existing code, so that is where the observer pattern comes into the scene ...

Here is the code i wrote to make a simple scenarion for observer pattern on my personal git_repo : LINK
Now we can do sth like that easily :

from pyalgorithm.dp.observer import *



print "I creatte the our subject"

c_s = ConcreteSubject()

c_s.my_x = 22

c_s.my_y =33



print "I notify my subscribers :"

c_s.values_changed() #that can be done dynamic but it is cool for now



print "Lets add a new XObserver"

x_o = ObserverX()

g_o = ObserverGeneral()

c_s.add_observer(x_o)



print "I notify my subscribers :"

c_s.values_changed() #that can be done dynamic but it is cool for now





print "Lets add a new GeneralObserver"

c_s.add_observer(g_o)

print "I notify my subscribers :"

c_s.values_changed() #that can be done dynamic but it is cool for now



print "The X observer doesnt want to know anything about us remove him"

c_s.remove_observer(x_o)



print "I notify my subscribers :"

c_s.values_changed() #that can be done dynamic but it is cool for now

The output for that will be as follow :

I creatte the our subject
I notify my subscribers :
Lets add a new XObserver
I notify my subscribers :
Im X observer and got : 22
Lets add a new GeneralObserver
I notify my subscribers :
Im X observer and got : 22
I got all of them Here is my values 22 and 33
The X observer doesnt want to know anything about us remove him
I notify my subscribers :
I got all of them Here is my values 22 and 33

Well i think it became pretty dynamic ,i have lots of ideas where i can use that pattern. As a conclusion what i can say is that "Head First Design patterns" book is changing my vision to OO programming.

TO BE CONTINUED ...