Shulou(Shulou.com)06/01 Report--

Today, the editor will share with you the relevant knowledge points about how to achieve the single responsibility principle of python. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article. Let's take a look.

First, encapsulation

Encapsulation is one of the important features of object-oriented programming.

(1) what is encapsulation

Encapsulation is an abstract object process, which contains the implementation details of the object's properties and behavior, and provides public access to the outside world.

This has several benefits:

Separate use and implementation. The public interface can be used directly, but there is no need to consider how it is implemented internally.

It has internal state hiding mechanism, which can realize information / state hiding.

(2) Encapsulation and access

As far as object-oriented programming is concerned, a class is a means to realize the abstraction of an object, and the encapsulated implementation is to abstract the properties and behavior of an object into attributes and methods in the class.

For example:

Object AudioFile, need to have a file name, but also need to be able to play and stop playing. With class encapsulation, it is similar to the following implementation:

Class AudioFil: def _ init__ (self, filename): self.filename = filename def play (self): print ("playing...") Def stop (self): print ("stop playing...")

The self parameter must be the first (leftmost) parameter passed in to the class method; Python automatically populates the instance object (that is, the body that calls the method) through this parameter. This parameter does not have to be called self, its location is important (C++ or Java programmers may prefer to call it this, because in these languages, the name reflects the same concept. In Python, this parameter always needs to be explicit.

After encapsulation, it is easy to access:

If _ _ name__ = "_ _ main__": file_name = "Vajra Gourd. MP3" current_file = AudioFil (filename=file_name) print (current_file.filename) current_file.play () current_file.stop () > Vajra Gourd. Mp3playing. Mp3. Stop playing Vajra Cucurbita. Mp3.

At the same time, the internal properties can be modified externally:

If _ _ name__ = = "_ _ main__": file_name = "Vajra Gourd .mp3" current_file = AudioFil (filename=file_name) print (current_file.filename) current_file.play () current_file.stop () current_file.filename = "Shuck and Beta" print (current_file.filename) current_file.play () current_file.stop () > > Vajra Gourd Baby. Mp3playing Vajra cucurbit. MP3... stop playing Vajra cucurbit. Mp3. Oggplaying and Beta. Ogg...stop playing and Beta. (III) privatization and access Control

Although internal properties or states can be modified externally, it is sometimes necessary to restrict external access to certain internal properties or methods for security reasons.

Some languages can explicitly specify valid access ranges for internal properties or methods. For example, in Java, keywords such as public and private explicitly provide access restrictions on internal properties and methods, but python also provides another way to control their access scope within the class:

Modify properties and methods with _ or _ _ to make them internal properties or methods.

Use _ _ method-name__ to implement method overloading.

1. Privatization of attributes and methods

For example:

Class AudioFil: def _ init__ (self, filename): self._filename = filename def play (self): print (f "playing {self._filename}...") Def stop (self): print (f "stop playing {self._filename}...") if _ _ name__ = = "_ _ main__": file_name = "King Kong cucurbit .mp3" current_file = AudioFil (filename=file_name) print (current_file._filename) current_file.play () current_file.stop ()

Note the format of _ filename. The beginning of a single underscore indicates that this is an internal variable of a class, which reminds programmers not to access this variable externally, even though it is accessible.

A stricter form is to use double underscores:

Class AudioFil: def _ init__ (self, filename): self.__filename = filename def play (self): print (f "playing {self.__filename}...") Def stop (self): print (f "stop playing {self.__filename}...") if _ _ name__ = "_ _ main__": file_name = "King Kong cucurbit .mp3" current_file = AudioFil (filename=file_name) print (current_file.__filename) # AttributeError: 'AudioFil' object has no attribute' _ filename' current_file.play () current_file.stop ()

Note the format of _ _ filename. The beginning of the double underscore indicates that this is an internal variable of a class, which gives more stringent external access restrictions, but can still achieve external access through special means:

# print (current_file.__filename) print (current_file._AudioFil__filename)

_ ClassName__attributename

In short, this kind of privatization means "guard against gentlemen but not villains", not to mention that it is not real privatization-pseudo privatization. There is a more accurate concept to describe this mechanism: variable name compression.

2, variable name compression

Python supports the concept of variable name compression (mangling, which acts as an extension)-- localizing certain variables within a class.

Compressed variable names are often mistaken for private attributes, but this is really just a way to localize the variable names created by the class: name compression does not prevent it from being read by out-of-class code.

The main purpose of this mechanism is to avoid namespace conflicts within the instance, rather than restricting access to variable names. Therefore, compressed variable names are better called "pseudo-private" rather than "private".

Operations that start with _ or _ _ inside the class are just an informal convention to let programmers know that this is a name that should not be modified (it doesn't make sense for Python itself).

3. Method overload

Python's built-in data types automatically support operations such as + operations, indexing, slicing, and so on, all through methods named in the _ _ method-name__ format inside the class of the corresponding object.

Method overloading can be used to implement objects that simulate built-in types (for example, sequences or numeric objects such as matrices), as well as built-in type interfaces expected in the simulation code.

The most common overloading method is the _ _ init__ constructor, which is used by almost every class to initialize instance properties or perform other startup tasks.

The special self parameters in the method and the _ _ init__ constructor are the two cornerstones of Python OOP.

For example:

Class AudioFil: def _ _ init__ (self, filename): self.__filename = filename def _ str__ (self): return f "I am" {self.__filename} "" def play (self): print (f "playing {self.__filename}...") Def stop (self): print (f "stop playing {self.__filename}...") if _ _ name__ = = "_ _ main__": file_name = "AudioFil (filename=file_name) print (current_file) # > I am" Vajra Gourd. Mp3 "(4) attribute references: getter, setter and property

Some languages use private properties through getter and setter to obtain and set internal properties. Python provides the property class to achieve the same goal. For example:

Class C: def _ init__ (self): self._x = None def getx (self)-> str: return self._x def setx (self, value): self._x = value def delx (self): del self._x x = property (getx, setx, delx) "if the'x 'property.") if _ _ name__ =' _ _ main__': c = C () c.x = "ccc" # call setx print (c.x) # call getx del c.x # call delx

The existence of property makes the acquisition, setting and deletion of attributes automatically built-in.

A more elegant way is to use the @ property decorator. For example:

Class C: def _ _ init__ (self): self._x = None @ property def x (self): "I am the 'x' property." Return self._x @ x.setter def x (self, value): self._x = value @ x.deleter def x (self): del self._xif _ _ name__ ='_ _ main__': c = C () c.x = "ccc" print (c.x) del c.x II, single responsibility principle (1) an example that does not meet the single responsibility principle

Now you need to deal with some audio files, which, in addition to some descriptive properties, have three behaviors: playing, stopping playback, and storing information:

Class AudioFile: def _ init__ (self, filename, author): self.__filename = filename self.__author = author self.__type = self.__filename.split (".") [- 1] def _ str__ (self): return f "I am" {self.__filename} "" def play (self): print (f "playing {self.__filename}...") Def stop (self): print (f "stop playing {self.__filename}...") Def save (self, filename): content = {} for item in self.__dict__: key = item.split ("_") [- 1] value = self.__dict__ [item] content [key] = value with open (filename+ ".txt" "a") as file: file.writelines (str (content) +'\ n') if _ _ name__ = ='_ _ main__': file_name = "King Kong Huluwa. MP3" author_name = "Yao Lizhong, Wu Yingju" current_file = AudioFile (filename=file_name,author=author_name) current_file.save (filename= "info_list")

This class works properly.

Notice the save method, which does some formatting before saving the file information. Obviously the later work is "temporarily added" and may also be used in other file types.

With the change of project requirements or other reasons, the diffusion of processing logic often occurs within the method, that is, the completion of a function requires a new function as a prerequisite.

From the point of view of the simplest code reusability, the reusable work within the method should be mentioned separately:

As for the level at which the public function is placed, please analyze it in detail.

Def info_format (obj): content = {} for item in obj.__dict__: key = item.split ("_ _") [- 1] value = obj.__dict__ [item] content [key] = value return contentclass AudioFile:. Def save (self, filename): content = info_format (self) with open (filename+ ".txt", "a") as file: file.writelines (str (content) +'\ n')

However, when the improved code encounters a functional change, it still requires a lot of effort to modify it on the original basis. For example, if you need to provide information search function, this kind of code may appear:

Class AudioFile:... Def save (self, filename):... Def search (self, filename, key=None):...

If the later search conditions change, or add new features, it will lead to functional diffusion within the class, which will further increase the complexity of the original code, and the readability will gradually become worse, especially not conducive to maintenance and testing.

(II) the principle of single responsibility

The principle of single responsibility (Single-Responsibility Principle,SRP) was developed by Robert C. Martin proposed it in Agile Software Development: principles, patterns, and practices. The responsibility here refers to the reason for the change of the class, and the single responsibility principle states that a class should have one and only one cause for its change, otherwise the class should be split.

This principle states that the object should not take on too many responsibilities, and if an object takes on too many responsibilities, there are at least two shortcomings:

A change in one responsibility may weaken or inhibit the ability of this class to perform other responsibilities.

When the client needs one of the responsibilities of the object, it has to include all the other unneeded responsibilities, resulting in redundant code or a waste of code.

For example: a module that compiles and prints reports. Imagine that such a module can be changed for two reasons.

First, the content of the report may change. Second, the format of the report may change. These two things change for different reasons. The single responsibility principle says that these two aspects of the problem are actually two separate responsibilities, so they should be in different classes or modules.

In short, the single responsibility principle holds that combining two things that change for different reasons at different times is a bad design.

Take a look at the modified code:

Class AudioFile: def _ init__ (self, filename, author): self.__filename = filename self.__author = author self.__type = self.__filename.split (".") [- 1] def _ str__ (self): return f "I am" {self.__filename} "" def play (self): print (f "playing {self.__filename}...") Def stop (self): print (f "stop playing {self.__filename}...") class AudioFileDataPersistence: def save (self, obj, filename):... class AudioFileDataSearch: def search (self, key, filename):... if _ name__ = ='_ main__': file_name = "King Kong Huluwa. MP3" author_name = "Yao Lizhong, Wu Yingju" current_file = AudioFile (filename=file_name) Author=author_name) data_persistence = AudioFileDataPersistence () data_persistence.save (current_file, filename= "info_list") data_search = AudioFileDataSearch () data_search.search (file_name, filename= "info_list")

But is it a reasonable choice to split the code?

Third, the principle of encapsulation and single responsibility

From the perspective of encapsulation, its purpose is to improve the cohesion and reusability of the code while providing interfaces, but the functional and comprehensive encapsulation is more unsafe.

The single responsibility principle achieves lower coupling and higher reusability by splitting code, but excessive splitting increases the complexity of interactions between objects.

With regard to the combination of the two, there are some issues that need to be paid attention to in advance:

What is the granularity of the requirements?

How high is the cost of maintenance?

As the basic concepts and practical principles of object-oriented programming, the two are actually causality-- if a class is cohesive, if it has a higher-level purpose, if its responsibilities match its name, then SRP will naturally appear. SRP is only the actual result of code optimization, and it is not a goal in itself.

These are all the contents of this article entitled "how to achieve the single responsibility principle of python". Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.