Review of the book Design Patterns on the .NET Platform
As you know, a book on design patterns authored by Sergey Teplyakov was recently published .
In order to support my esteemed developer by me (Sergey himself, despite his relocation abroad, still considers himself ours - go to his blog for proof), did not spare the money and immediately bought an electronic version. Before that, I read a gang of four and Design Patterns Head First , therefore, in principle, there is something to compare.
The book takes a little more than 300 pages, which is quite possible to master in a week of leisurely reading. The book is divided into 4 parts:
The splitting of patterns into such groups has long been settled and stuck. Unlike the gang of four, Sergey’s book has a chapter on SOLID design principles (in fact, the book of the four gangs of these principles in the form in which we are familiar with them could not be, since they were formulated later). In the book of the gang of four there is a practical chapter that illustrates the patterns on the example of developing a text editor. Throughout the text, Sergey uses the problems that arise when developing a log processing application (as I understand it, the topic is close to what Sergei is doing at Microsoft) as examples. There is no separate practical chapter, as is the case with the gang of four. In principle, the author is well able to disassemble the patterns on this example, however, I would like to note that everything is given too easily, that is, in the course of the narration there are no particular problems - everything lays down like clockwork. Most likely, it was conceived when writing, but it seemed to me not very pleasant that there is no Challenge anywhere (sorry, for barbarism). An example with a text editor looks more interesting, in my opinion. To the shortcomings of the book I, of course, cannot take this remark directly.
This book is a rare case when I just picked up a book and read it from beginning to end. And I must tell you that the book reads very, very easily. Of course, a developer who has just begun his acquaintance with patterns is unlikely to be able to read the entire book so carelessly, but I think that it’s still difficult for a beginner to imagine a book simpler to understand than this one. The style and form of presentation chosen by the author contributes to a deeper understanding of the patterns: the book is in many ways a reflection of one’s own experience, not a stupid compilation of other people's thoughts, and this is very appealing. The examples, although I didn’t really like the chosen type of application, are still good and cope with their task. For non-newbies, it may be interesting to compare your experience with the author. Often I found confirmation of my own thoughts that I had no one to discuss with. Therefore, personally with me, in the process of reading a book, an internal dialogue with the author constantly occurred.
')
As for the target audience of the book, I would like to note that even in .NET there are many of its own buns, but there are very few such buns that would have a huge impact on the shape of the patterns. With a run-up, I can only remember that in .NET you can make an explicit interface implementation and simplify some patterns using delegates. Well, yes - there is no multiple inheritance, which, for example, Bob Martin considers, in fact, a cant of the .NET team, since the “deadly diamond of death” is not so terrible as it is painted, but multiple inheritance can be very useful in some cases ( although it happens not to say so often). Since there are not so many features of the .NET platform, everyone who is interested in patterns can read the book, regardless of the language of religion.
The author gives classical diagrams of patterns that use inheritance thickly, but very often gives simplified versions, since in the classical form patterns are used quite rarely. In general, the author does not forget to point out that one should not blindly use patterns and learns to include the brain, dancing from the task and the requirements. I also note that it is important that the use of patterns is considered in conjunction with the writing of unit tests.
In the topic, where Sergey announced that he was writing a book, there were people who did not fail to say that “patterns are garbage, people will talk, and then they make factories of factories of factories with megaphacades and another 100,500 patterns where it is not necessary, why all these books on patterns, all these patterns are already understandable. ” In my humble opinion, most of these people write unreadable underengineered shit code, which is then rewritten a thousand times. This time. Secondly, yes, thoughtless application of patterns is bad and in a good book it is also written about it. Programming is engineering, and in engineering there are no silver bullets and universal answers to all questions. Therefore, good programmers always weigh what they put at stake and what they are prepared to bring to the altar of complexity in order to solve the problem. Unfortunately, there are no books that teach such art (if someone has seen them share it), because understanding how to strike a balance between complexity, simplicity and power of solutions is possible only with the help of many years of hard training for real tasks.
I liked the idea in the book that following (even correct and good following) all principles does not guarantee achievement of a chic design of the application. Everything depends on the task, on how the PLO will fall on such a task, in the end.
The book does not cover the following classical patterns: "bridge", "flyweight", "memento", "prototype".
The prototype pattern is rather dull and is realized through the terrible ICloneable (it does not give an understanding of what kind of copy it is - deep or superficial), although the implementation, of course, can be improved. Maybe that's why this pattern was excluded from the book. The remaining patterns are quite interesting and I do not know why they were excluded from consideration. The book also does not consider any "composite" patterns, such as MVC, MVP, MVVM. Rather, they are affected by the glimpse, but the author does not delve into them, and, I think, this is correct, since a separate book can be devoted to each of them.
One of the few moments where I do not quite agree with the author was the moment about the release of undeclared exceptions by heirs, if these exceptions are not specified in the base class contract, or are not specified in the XML comments in the appropriate section. It is not a bad practice to indicate possible exceptions, declare them in contracts (I did not use contracts, but from the book I realized that it is possible to declare possible types of exceptions) fly only declared exceptions. How many methods have you seen in BCL, which climb, say, into the file system and declare all types of possible exceptions? That's right, there are no such methods. The concept of checked exceptions .NET developers initially abandoned. The error handling system through exceptions is still a big and fat hemorrhoids for those who want to develop stable applications. For correct error handling through exceptions, a lot of things are required: proper architecture construction, competent selection of exception types, competent writing of tests, contracts, and so on. If at least in one of these areas the development team has problems, then the application will fall with enviable regularity, and often from all sorts of “harmless exceptions” when the work could be continued.
In conclusion, I would like to say thanks to Sergey for a wonderful book, write more! On a ten-point scale, I would rate the book at 8-8.5.
In order to support my esteemed developer by me (Sergey himself, despite his relocation abroad, still considers himself ours - go to his blog for proof), did not spare the money and immediately bought an electronic version. Before that, I read a gang of four and Design Patterns Head First , therefore, in principle, there is something to compare.
The book takes a little more than 300 pages, which is quite possible to master in a week of leisurely reading. The book is divided into 4 parts:
- Behavior patterns
- Generating patterns
- Structural Patterns
- Design Principles
The splitting of patterns into such groups has long been settled and stuck. Unlike the gang of four, Sergey’s book has a chapter on SOLID design principles (in fact, the book of the four gangs of these principles in the form in which we are familiar with them could not be, since they were formulated later). In the book of the gang of four there is a practical chapter that illustrates the patterns on the example of developing a text editor. Throughout the text, Sergey uses the problems that arise when developing a log processing application (as I understand it, the topic is close to what Sergei is doing at Microsoft) as examples. There is no separate practical chapter, as is the case with the gang of four. In principle, the author is well able to disassemble the patterns on this example, however, I would like to note that everything is given too easily, that is, in the course of the narration there are no particular problems - everything lays down like clockwork. Most likely, it was conceived when writing, but it seemed to me not very pleasant that there is no Challenge anywhere (sorry, for barbarism). An example with a text editor looks more interesting, in my opinion. To the shortcomings of the book I, of course, cannot take this remark directly.
This book is a rare case when I just picked up a book and read it from beginning to end. And I must tell you that the book reads very, very easily. Of course, a developer who has just begun his acquaintance with patterns is unlikely to be able to read the entire book so carelessly, but I think that it’s still difficult for a beginner to imagine a book simpler to understand than this one. The style and form of presentation chosen by the author contributes to a deeper understanding of the patterns: the book is in many ways a reflection of one’s own experience, not a stupid compilation of other people's thoughts, and this is very appealing. The examples, although I didn’t really like the chosen type of application, are still good and cope with their task. For non-newbies, it may be interesting to compare your experience with the author. Often I found confirmation of my own thoughts that I had no one to discuss with. Therefore, personally with me, in the process of reading a book, an internal dialogue with the author constantly occurred.
')
As for the target audience of the book, I would like to note that even in .NET there are many of its own buns, but there are very few such buns that would have a huge impact on the shape of the patterns. With a run-up, I can only remember that in .NET you can make an explicit interface implementation and simplify some patterns using delegates. Well, yes - there is no multiple inheritance, which, for example, Bob Martin considers, in fact, a cant of the .NET team, since the “deadly diamond of death” is not so terrible as it is painted, but multiple inheritance can be very useful in some cases ( although it happens not to say so often). Since there are not so many features of the .NET platform, everyone who is interested in patterns can read the book, regardless of the language of religion.
The author gives classical diagrams of patterns that use inheritance thickly, but very often gives simplified versions, since in the classical form patterns are used quite rarely. In general, the author does not forget to point out that one should not blindly use patterns and learns to include the brain, dancing from the task and the requirements. I also note that it is important that the use of patterns is considered in conjunction with the writing of unit tests.
In the topic, where Sergey announced that he was writing a book, there were people who did not fail to say that “patterns are garbage, people will talk, and then they make factories of factories of factories with megaphacades and another 100,500 patterns where it is not necessary, why all these books on patterns, all these patterns are already understandable. ” In my humble opinion, most of these people write unreadable underengineered shit code, which is then rewritten a thousand times. This time. Secondly, yes, thoughtless application of patterns is bad and in a good book it is also written about it. Programming is engineering, and in engineering there are no silver bullets and universal answers to all questions. Therefore, good programmers always weigh what they put at stake and what they are prepared to bring to the altar of complexity in order to solve the problem. Unfortunately, there are no books that teach such art (if someone has seen them share it), because understanding how to strike a balance between complexity, simplicity and power of solutions is possible only with the help of many years of hard training for real tasks.
I liked the idea in the book that following (even correct and good following) all principles does not guarantee achievement of a chic design of the application. Everything depends on the task, on how the PLO will fall on such a task, in the end.
The book does not cover the following classical patterns: "bridge", "flyweight", "memento", "prototype".
The prototype pattern is rather dull and is realized through the terrible ICloneable (it does not give an understanding of what kind of copy it is - deep or superficial), although the implementation, of course, can be improved. Maybe that's why this pattern was excluded from the book. The remaining patterns are quite interesting and I do not know why they were excluded from consideration. The book also does not consider any "composite" patterns, such as MVC, MVP, MVVM. Rather, they are affected by the glimpse, but the author does not delve into them, and, I think, this is correct, since a separate book can be devoted to each of them.
One of the few moments where I do not quite agree with the author was the moment about the release of undeclared exceptions by heirs, if these exceptions are not specified in the base class contract, or are not specified in the XML comments in the appropriate section. It is not a bad practice to indicate possible exceptions, declare them in contracts (I did not use contracts, but from the book I realized that it is possible to declare possible types of exceptions) fly only declared exceptions. How many methods have you seen in BCL, which climb, say, into the file system and declare all types of possible exceptions? That's right, there are no such methods. The concept of checked exceptions .NET developers initially abandoned. The error handling system through exceptions is still a big and fat hemorrhoids for those who want to develop stable applications. For correct error handling through exceptions, a lot of things are required: proper architecture construction, competent selection of exception types, competent writing of tests, contracts, and so on. If at least in one of these areas the development team has problems, then the application will fall with enviable regularity, and often from all sorts of “harmless exceptions” when the work could be continued.
In conclusion, I would like to say thanks to Sergey for a wonderful book, write more! On a ten-point scale, I would rate the book at 8-8.5.
Source: https://habr.com/ru/post/260649/
All Articles