You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Design_Patterns_In_Python.md
+10-13Lines changed: 10 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -191,21 +191,18 @@ The specific UML for this example is this.
191
191
## Composite ##
192
192
## Decorator ##
193
193
## Facade ##
194
-
###The Purpose###
194
+
###The Purpose###
195
195
196
196
The facade pattern is used to make one object with a simple interface represent a complicated system. The problem often occurs in programming where you have a series of interconnected classes where the functions must be called in a certain order or have complicated interdependencies.
197
197
198
198
This pattern is to give a standard interface to such a system, so you don't have to rely on reading how you call the system in one of the files or look at example usage.
199
-
<!--more-->
199
+
200
200
### The Pattern ###
201
-
Here is a <ahref="http://en.wikipedia.org/wiki/Unified_Modeling_Language"target="_blank">UML</a> diagram representing the pattern.
201
+
Here is a UML diagram representing the pattern.
202
202
203
203
<!--
204
204
[caption width="380" align="aligncenter"]<a href="http://www.dofactory.com/Patterns/Diagrams/facade.gif"><img src="http://www.dofactory.com/Patterns/Diagrams/facade.gif" width="380" height="272" class /></a> UML for Facade pattern[/caption]
205
205
-->
206
-
UML is a very useful tool however I have not used a lot yet. It provides a (mostly) standardised way of representing system structure for object oriented programming. I intend to use a UML diagram to represent each pattern in this series, I will explain them so hopefully you don't need to know UML to follow what's going on.
207
-
208
-
This is a nice and simple UML diagram with the following elements; the facade box represents a class, the boxes in the subsystem box could be any object such as a class or a function and the lines between them indicate some relationship.
209
206
210
207
This shows that the pattern is just one class which groups together a lot of other objects and uses them in some way.
211
208
@@ -312,11 +309,10 @@ All of the code for this series can be found in <a href="https://github.com/davi
312
309
## Interpreter ##
313
310
## Iterator ##
314
311
This post will be about the Iterator pattern which is a behavioural pattern.
312
+
315
313
###The Purpose###
316
314
The idea behind this pattern is to have an object which you can loop over without needing to know the internal representation of the data. While in python nothing is private so you can find out the internals of the class, the iterator pattern gives you a standard interface.
317
315
318
-
<!--more-->
319
-
320
316
I think the best example of an iterator in python is using a list. As I'm sure you know this is how you would iterate over a list in python.
321
317
```python
322
318
list= ["one", "two", "three"]
@@ -333,7 +329,7 @@ three
333
329
334
330
The goal of this pattern in python is to be able to do that with a user defined class.
335
331
336
-
###The Pattern###
332
+
###The Pattern###
337
333
338
334
This is quite a small pattern so I will focus more on the implementation detail than the design.
339
335
@@ -353,7 +349,8 @@ They focus on pythons magic methods, which are those with double underscores sur
353
349
354
350
I'm going to briefly talk about the protocols for mutable and immutable containers, and iterators.
355
351
356
-
<h3>Immutable Containers</h3>
352
+
####Immutable Containers####
353
+
357
354
An immutable container is one where you cannot change the individual items. For this you only need to be able to get the length of it and access individual items.
358
355
359
356
The python magic methods for an immutable container are.
@@ -372,7 +369,7 @@ def __getitem__(self, key):
372
369
373
370
Again the exceptions mentioned in __getitem__ are convention, but it's important for writing idiomatic python.
374
371
375
-
<h3>Mutable Containers</h3>
372
+
####Mutable Containers####
376
373
As you might expect a mutable container has the same methods for accessing items as an immutable container, but adds ways of setting or adding them.
377
374
378
375
Here are the magic methods.
@@ -412,7 +409,7 @@ For an immutable container you probably want to have some way of adding elements
412
409
413
410
There are other functions you can add such as __reversed__(self) and __contains__(self, item) but they are not needed for core functionality. They are very well described <ahref="http://www.rafekettler.com/magicmethods.html#sequence"target="_blank">here</a>.
414
411
415
-
<h3>Iterators</h3>
412
+
####Iterators####
416
413
417
414
The protocol for an iterator is very simple.
418
415
@@ -716,7 +713,7 @@ Here is the specific UML diagram for these.
716
713
717
714
The code for this implementation is found in <ahref="https://github.com/davidcorne/Design-Patterns-In-Python/blob/master/Behavioural/Strategy_old.py"target="_blank">this file</a>.
718
715
719
-
<h3> Second Example </h3>
716
+
__Second Example__
720
717
721
718
The previous example is more how you would implement this pattern in a statically typed language such as C++ or C#. This is a more pythonic approach which will take some advise I heard in a talk; classes with only a __init__ function and one other function are functions in disguise. As functions are first class objects in python there is a lot we can do with them and I believe this gives a more pythonic variant of the strategy pattern.
0 commit comments