text Mithril-prezentation对OO模式和设计

Posted 2021-05-01

{
  "Title": "OO- patterns and designs",
  "slides": [
    {
      "id": "eb4c4664-b947-11e8-96f8-529269fb1459",
      "title": "SLIDE _11 DIP",
      "contents": "__Dependency inversion__\n===\n---\n![IP](https://image.slidesharecdn.com/openclosedprinciplekata-130915060011-phpapp01/95/open-closed-principle-kata-9-638.jpg?cb=1379225200)\n>High level modules should not depend on low level modules rather both should depend on abstraction.\n\n>Abstraction should not depend on concrete details; rather details should depend on abstractions.”\n\nIn JS the __ concern__ of the dependancy inversion principle is to ensure decoupling between components and their depenencies.\n\n__Dependency Injection__ is __Not__ related to the principle of dependancy inversion.\n\n__DI__ a different aspect of __Inversion of Control__ in which the concern being inverted is \n__how a component obtains__ its dependencies rather than __who defines__ the interface.\n\nin DI dependencies are supplied to a component rather than the component obtaining the dependency by means of creating an instance of the dependency\n\nhttp://aspiringcraftsman.com/2012/01/22/solid-javascript-the-dependency-inversion-principle/",
      "isSelected": false
    },
    {
      "id": "eb4c4de4-b947-11e8-96f8-529269fb1459",
      "title": "SLIDE _10- ISP",
      "contents": "__Interface Segregation Principle__\n===\n-----\n![ISP](http://deviq.com/wp-content/uploads/2014/11/InterfaceSegregation.jpg)\n\n#### The cohesion of __interfaces within a system__.\n\n##### ... JS does not have interfaces ...\n\n>#### Clients should not be forced to depend on __methods__ they do not use.\n\n__The operation’s signature__ :\nEvery operation declared by an object specifies the operation’s name, the objects it takes as parameters, and the operation’s return value. \n\n__The set of all signatures__ defined by an object’s operations is called the interface to the object.\n\nhttp://aspiringcraftsman.com/2012/01/08/solid-javascript-the-interface-segregation-principle/",
      "isSelected": false
    },
    {
      "id": "eb4c5032-b947-11e8-96f8-529269fb1459",
      "title": "SLIDE _9 - LSP",
      "contents": "__Liskov substitution__\n===\n---\n![lsp](https://www.texnoman.uz/uploads/image/fdb79615dcfbce156440b9d453b7b4d8.jpg)\n\n> ### Any extended entity should be able to replace the entity which it is an extension of without modifiyng the  __behavior__ of the application.\n\n```\nif S is a subtype of T, \nthen objects of type T\nin a program may be replaced \nwith objects of type S \nwithout altering any of the desirable properties of that program```\n\n\n\n\n#### “a violation of LSP is a latent violation of OCP”.\n\n\nhttp://aspiringcraftsman.com/2011/12/31/solid-javascript-the-liskov-substitution-principle/",
      "isSelected": false
    },
    {
      "id": "eb4c5244-b947-11e8-96f8-529269fb1459",
      "title": "SLIDE 8 OCP",
      "contents": "__Open/closed__\n==\n----\n![ocp](https://image.slidesharecdn.com/openclosedprinciplekata-130915060011-phpapp01/95/open-closed-principle-kata-7-638.jpg?cb=1379225200)\n\n>#### Software entities (classes, modules, functions, etc.) should be __open for extension but closed for modification__.\n\n#### The __foundation__ for building reusable maintainable code.\n\n\n\n #### __open for extension:__  reusing an element in different contexts\n\n#### __ closed to modification__  the changes do not require a modification in the behaviour of the element.\n\n### __Leads to__ \n* #### Loose coupling\n* #### improve readability\n* #### reducing the risk of breaking existing functionality.\n\nhttp://aspiringcraftsman.com/2011/12/19/solid-javascript-the-openclosed-principle/",
      "isSelected": false
    },
    {
      "id": "eb4c5d20-b947-11e8-96f8-529269fb1459",
      "title": "SLIDE 7 SRP",
      "contents": "__Single Responsibility__\n===\n-----\n![srp](https://cdn-images-1.medium.com/max/839/1*3YaCOImYwSA4XTQS5nF5bQ.png)\n> ### A class should have __only one reason to change__\n\n###  __NOT__ the _same as only do one thing_.\n\n![not srp](http://www.dotnetcurry.com/images/software-gardening/srp/single-responsibility-principle.jpg)\n\n----\n### An object should have a __cohesive set of behaviors__, together comprising a single responsibility that, if changed, would require the modification of the object’s definition. \n\n### __cohesion__\n* #### derives from the functional relatedness of elements in a module.\n\n* #### This leads to better/concise tests and improved code reliability\n \n### code smells:\n   * #### large setups for testing,\n   * #### more than one contextually different piece of code\n\nhttp://aspiringcraftsman.com/2011/12/08/solid-javascript-single-responsibility-principle/",
      "isSelected": false
    },
    {
      "id": "eb4c5f64-b947-11e8-96f8-529269fb1459",
      "title": "SLIDE 6 - Princips of OOD",
      "contents": "__Principles of Object Oriented Design__\n===\n---\n#### Principles are distillation of __patterns__ in nature.\n#### __ Principles__   constrain our code and helps keep our code simple and bug free.\n\n #### __Robert C. Martin__ promoted  11 Principles\n #### Detailing how to __design (5) and package (6)__ software.\n  \n\n#### Michael Feathers coined the term __SOLID PRINCIPLES__ \n\n#### http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod\n\n![solid](https://cdn-images-1.medium.com/max/606/1*yO6YGExWLJl5VOUL61xXvQ.jpeg)",
      "isSelected": false
    },
    {
      "id": "eb4c6180-b947-11e8-96f8-529269fb1459",
      "title": "SLIDE 5 - GOF",
      "contents": "### __Patterns__ are __repetitive__ designs;\n### __simplify__ solutions to common problems.\n![fractal](https://i.pinimg.com/736x/30/94/61/3094618c00ddbf7c5d4b2558d44ee6b9--golden-ration-fractals-in-nature.jpg)\n __The__ Gang of Four\n====\n-----\n#### __Design Patterns__: Elements of Reusable Object-Oriented Software \n##### by _Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides_.\n----\n<table>\n<tr>\n<th>__Creational patterns (5)__</th>\n<th>__Structural patterns (7)__</th>\n<th>__Behavioral patterns (11)__</th>\n</tr>\n<tr>\n<td>Factory method pattern</td>\n<td>Adapter pattern</td>\n<td>Chain-of-responsibility pattern</td>\n</tr>\n<tr>\n<td>Abstract factory pattern</td>\n<td>Bridge pattern</td>\n<td>Command pattern</td>\n</tr>\n<tr>\n<td>Singleton pattern</td>\n<td>Composite pattern</td>\n<td>Interpreter pattern</td>\n</tr>\n<tr>\n<td>Builder pattern</td>\n<td>Decorator pattern</td>\n<td>Iterator pattern</td>\n</tr>\n<tr>\n<td>Prototype pattern</td>\n<td>Facade pattern</td>\n<td>Mediator pattern</td>\n</tr>\n<tr>\n<td></td>\n<td>Flyweight pattern</td>\n<td>Memento pattern</td>\n</tr>\n<tr>\n<td></td>\n<td>Proxy pattern</td>\n<td>Observer pattern</td>\n</tr>\n<tr>\n<td></td>\n<td></td>\n<td>State pattern</td>\n</tr>\n<tr>\n<td></td>\n<td></td>\n<td>Strategy pattern</td>\n</tr>\n<tr>\n<td></td>\n<td></td>\n<td>Template method pattern</td>\n</tr>\n<tr>\n<td></td>\n<td></td>\n<td>Visitor pattern</td>\n</tr>\n</table>\n",
      "isSelected": false
    },
    {
      "id": "eb4c63a6-b947-11e8-96f8-529269fb1459",
      "title": "SLIDE 4 - Princ of Design",
      "contents": "# __PRINCIPLES (...OF DESIGN)__\n----------------\n\n### Occam's razor\n >\"the simpleset solution is generely the correct one\"\n\n### Hanlon's razor:\n > \"Never attribute to malice that which is adequately explained by stupidity\"\n\n### __QED__ \n#### The __less complex__ the system - the more correct it will tend to be.",
      "isSelected": false
    },
    {
      "id": "eb4c6a40-b947-11e8-96f8-529269fb1459",
      "title": "SLIDE 3 bad design",
      "contents": "# __On Bad Design__\n--------------\n### At the heart of this issue is our __lack__ of a good working _definition_ of “bad” design.\n\n**Uncle Bob**: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod\n\n### I would say that a system that allowed other metathings to be done in the ordinary course of programming (like __changing__ what inheritance means, or what is an instance) is a bad design.\n\n**Alan Kay**  http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html\n\n----------------------\n\n![martin fowler](https://cdn-images-1.medium.com/max/638/1*00A0l2A6fyNatudL7m5x6Q.jpeg)\n## A piece of software that __fulfills__ its requirements and yet __exhibits__ any or all of the following three traits has a bad design.\n\n### __Rigidity__\n#### It is hard to change. (because every change affects too many other parts of the system.)\n### __Fragility__\n#### When you make a change, unexpected parts of the system break.\n### __Immobility__\n#### It is hard to reuse in another application. (because it cannot be disentangled from the current application)",
      "isSelected": false
    },
    {
      "id": "eb4c6c66-b947-11e8-96f8-529269fb1459",
      "title": "SLIDE 2 good design",
      "contents": "# __On Good Design__\n--------------\n# The __key__ in making great and growable systems is  much more to design how its modules __communicate__ rather than what their internal properties and behaviors should be. \n\n**Alan Kay**\n http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html\n\n!['communication'](http://www.jot.fm/issues/issue_2004_04/article9/images/fig1.gif)",
      "isSelected": false
    },
    {
      "id": "eb4c6ef0-b947-11e8-96f8-529269fb1459",
      "title": "SLIDE 01 What?",
      "contents": "# __What goes wrong with software?__\n-----------------------------\n\n>### __Efficient__ code organization is about Dependency Management.\n***Uncle Bob\n\n### __Most__ software engineers don’t set out to create “bad designs”.\n\n### Yet __most__ software eventually degrades to the point where someone will declare the design to be unsound.\n\n### __Why__ does this happen?\n\n### __Was__ the design poor to begin with, or did the design actually degrade like a piece of rotten meat?\n\n**Uncle Bob** http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod\n![](http://2017.agilesummit.gr/wp-content/uploads/2017/04/UncleBob-300x300.jpg)",
      "isSelected": false
    },
    {
      "id": "eb4c7120-b947-11e8-96f8-529269fb1459",
      "title": "INTRO",
      "contents": "![randy pauch -- the last lecture](http://img.picturequotes.com/2/28/27723/youve-got-to-get-the-fundamentals-down-because-otherwise-the-fancy-stuff-is-not-going-to-work-quote-1.jpg)\n\n\n  # __A significant barrier to progress__ _in computer science_ \n## is the fact that many practitioners are ignorant of the history of computer science: old accomplishments (and failures!) are forgotten, and consequently the industry reinvents itself every 5-10 years. \n\n**Alan Kay**  The Cuneiform Tablets of 2015\n  http://www.vpri.org/pdf/tr2015004_cuneiform.pdf\n![alan kay](http://cyborganthropology.com/wiki/images/e/e1/Alan-kay.jpg )"    ,
      "isSelected": false
     }
  ]
}