{"id":23100539,"url":"https://github.com/pseudoincorrect/design_patterns_python","last_synced_at":"2025-04-03T20:44:39.532Z","repository":{"id":92888881,"uuid":"179335589","full_name":"pseudoincorrect/Design_Patterns_Python","owner":"pseudoincorrect","description":"Design Pattern Course","archived":false,"fork":false,"pushed_at":"2019-05-16T11:18:56.000Z","size":48,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-02-09T09:09:56.979Z","etag":null,"topics":["design-patterns","python"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/pseudoincorrect.png","metadata":{"files":{"readme":"README","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-04-03T17:12:37.000Z","updated_at":"2021-04-14T10:54:32.000Z","dependencies_parsed_at":null,"dependency_job_id":"e7ff9f94-8390-43dc-8dd0-933efeba9a15","html_url":"https://github.com/pseudoincorrect/Design_Patterns_Python","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pseudoincorrect%2FDesign_Patterns_Python","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pseudoincorrect%2FDesign_Patterns_Python/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pseudoincorrect%2FDesign_Patterns_Python/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pseudoincorrect%2FDesign_Patterns_Python/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/pseudoincorrect","download_url":"https://codeload.github.com/pseudoincorrect/Design_Patterns_Python/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247078801,"owners_count":20879950,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["design-patterns","python"],"created_at":"2024-12-16T23:33:01.720Z","updated_at":"2025-04-03T20:44:39.512Z","avatar_url":"https://github.com/pseudoincorrect.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"-------------------------------------------------------------------------------\n- \"SOLID\" DESIGN PRINCIPLES ---------------------------------------------------\n-------------------------------------------------------------------------------\n\nS - Single Responsability Principle\nA class should only have one reason to change\nSeparation of concerns - different classes handling different, independant\ntasks/problems\n\nO - Open-Closed Principle\nA class should be open for extension, closed for modification\nIf you go back to a class and modify it (change code inside a already written \nfunctions) it's probably a better idea to use OOP technics (such a inheritance)\nto extend the class itself, or refactor the class to separate the concerns\n\nL - Liskov Substitution Principle\nYou should be able to substitue a class by a type or a subtype\nOn the example with square and rectangle, we violation of the Principle.\nThere, for the Square class, when changing one of the edge size, all edges\nshould change. in the example it does not, hence the error of calculation\n\nI - Interface Segregation Principle\nDon't put too much into a single interface, split them.\nYAGNI - You Ain't Going to Need It, don't write method/function you don't \nneed. write them when you need it. Yeah, I know the feeling of uncompletion\nstruck you hard, but it's life\n\nD - Dependency Inversion Principle\nHigh Level Modules should not depend on low level ones, use abstraction instead\n\n-------------------------------------------------------------------------------\n- CREATIONAL DESIGN PATTERNS --------------------------------------------------\n-------------------------------------------------------------------------------\n\nBuilder\nSeparate component builder for when obect constructs get too complicated\nWe can use sub-builders to divide the overal build problem\nusually used after the instance initialization\nWe can use fluent interface (return self) to chain the builders \n\nFactories\nMethods usually used to initialize a class in various different way\nCan be a static class method\nMyClass: @static MyClass.initializeThisWay(args)\n\nPrototypes\nMake an object from an existing object \nin python, with copy.deepcopy\nwe can use a prototype factory: an object that store multiple \nprototypes. When the need of creating an object arise, we can pick of  the\nprototype, copy it, and use it\n\nSingleton\nTricky one\nWhen you need to ensure that only one instance of a class exists.\ncan be done with Decorator of metaclass in python.\nGeneraly Tough to test (ex: singleton of a database oject). to solve this issue\nwe can use dependency injection (injecting a mock Db in the test case)\n\n-------------------------------------------------------------------------------\n- STRUCTURAL DESIGN PATTERNS --------------------------------------------------\n-------------------------------------------------------------------------------\n\nAdapter\nconvert an interface you get to an interface you need\n\nBridge\nDecouple abstration from implementation\nexample: a Point class can use cartesian or polar notation\nwe can use a bridge for method that use Point without the \nneed to expose the complexity of cartesian or polar representations\n\nComposite\nUseful for reccursion. we can use this pattern to create an \"object A\"\ncontaining multiple \"objects B\" and apply the same operation (function) \nto them if for instace we have a list of As and Bs. A is a composite of \nobject B (several B contain in A)\n\nDecorators\nAttach additional responsabilities to objecs\n\nFacade\nprovide a simple iterface for other complicated interfaces while keeping\nthe access to lower level features (if needed).\n\nFlyweight\nUsed to support large number of objects. example: storing numbers that \nreference to strings/sentences rather that storing them directly\n\nProxy\nprovide an object that forward the calls to an object while performing \nadditional functions ex: login \n\n-------------------------------------------------------------------------------\n- BEHAVIORAL DESIGN PATTERNS --------------------------------------------------\n-------------------------------------------------------------------------------\n\nResponsability Chain\nallows component to process information/event in chain\n\nCommand\nencapsulate request inside a seperate object instead of calling them directly\ngood for audit, undo,redo, database \n\nInterpreter\nTransform textual inputs into OOP structures (related: compiler theory)\n\nIterator\nProvide an interface for accessing the elements of an aggregated object\n__iter__ and __next__ in python, OR yield() (preferred)\n\nMediator\nProvide mediation between two objects (ex: chat room)\nbasically an object that contain other objects and orchestrate them\n\nMemento\nYield token representing the state of a system (snapshot)\n\nOberserver\nAllows notifications of changes in a system (Event, Observables, etc...)\n\nState\nState machine (what else to say)\n\nStrategy\ndefine the high level functionality of a system. the details are\nfilled by an implementor (low level function)\nStrategy use Composition (we inject the low lev object into the Strategy)\n\nTemplate\nSame as above but with inheritance\n\nVisitor\nAllows non intrusive addition of functionality to hierarchies\nex: adding functionality in a separate class to traverse a Object containing\na complicated data structure.\n\n-------------------------------------------------------------------------------\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpseudoincorrect%2Fdesign_patterns_python","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpseudoincorrect%2Fdesign_patterns_python","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpseudoincorrect%2Fdesign_patterns_python/lists"}