Hey folks! few weeks ago i started a new challenge to learn about one design pattern everyday i called it\n\"#DesignPatternsEveryday\".
\nSince i completed the challenge i thought i should share briefly what i learned about design patterns, let's get\nstarted.
\nI will be going over most of the patterns and going to explain them in my own words, so if you find any mistakes or\nmisinformation please let me know. i'm not a design patterns expert.
\nTable of Contents
\n\"Design patterns are typical solutions to common problems in software design. Each pattern is like a blueprint that you\ncan customize to solve a particular design problem in your code.\" - refactoring.guru
\nThere are 3 categories of design patterns, we are going to cover them one by one.
\nAlso note that, One thing is really important for utilizing design patterns in your project.
\nNever start with the mindset of \"okay I'm going to use {this pattern} in the codebase\"
Judge & analyze the code base, plan the logic and implementation first then apply design patterns to solve any\nparticular problem only IF NECESSARY.
\n\n\nDesign patterns are solution to problems, not solution finding problems.
\n
Abstract factory is a creational design pattern which allows us to produce families of objects without specifying their\nconcrete classes.
\nSuppose you are creating a drawing app where you'll have tools like \"draw box\", \"draw circle\" but you also need rounded\nvariants of box & circle, in that case you can create a factory for \"ShapeFactory\" and \"RoundedShapeFactory\" which will\nreturn respective shapes.
\nAbstract factory pattern could be helpful in scenarios while you need to have a framework work cross platform, for\nexample \"Electronjs\". i dont know how electronjs handles that probably not with factory pattern but it can be\nimplemented with factory pattern.
\n\n\n\n
class Button {\n render() {}\n}\n\nclass Factory {\n createButton() {}\n}\n\nclass WinButton extends Button {\n render() {\n return \"<button class='windows'></button>\";\n }\n}\n\nclass LinuxButton extends Button {\n render() {\n return \"<button class='linux'></button>\";\n }\n}\n\nclass WinFactory extends Factory {\n createButton() {\n return new WinButton();\n }\n}\nclass LinuxFactory extends Factory {\n createButton() {\n return new LinuxButton();\n }\n}\n\nclass AbstractFactory {\n static factory(type) {\n switch (type) {\n case 'windows':\n return new WinFactory();\n case 'linux':\n return new LinuxFactory();\n\n default:\n break;\n }\n }\n}\n\nlet guiFactory = AbstractFactory.factory('linux');\nlet button = guiFactory.createButton();\nconsole.log(button.render());Builder pattern is creational design pattern which allows us to create complex objects in a step by step manner. It\nallows us to create different type of objects with same code.
\nThink of it as car assembly line. The car will be assembled with parts gradually step by step, firstly its chassis will\nbe setup then the engine, radiator, wheels, seats, doors. and by modifying these steps in the assembly line we can\ncreate different types of car models with the same assembly line.
\nBuilder pattern is useful when you want to create various objects with different representation without creation\nsubclasses for each of them.
\nI implemented builder pattern in one of my previous project\nEvolution Aquarium to build different kind of Boids with different\nbehaviours and traits.
\n\n\n
class Car {\n constructor(engine, fuelTank, seats) {\n this.engine = engine;\n this.fuelTank = fuelTank;\n this.seats = seats;\n }\n\n printSpecs() {\n console.log(this.engine, this.fuelTank, this.seats);\n }\n}\nclass CarBuilder {\n constructor() {\n this.engine = '';\n this.seats = '';\n this.fuelTank = '';\n }\n\n addSeats(name) {\n this.seats = name;\n return this;\n }\n addEngine(value) {\n this.engine = value;\n return this;\n }\n addFuelTank(value) {\n this.fuelTank = value;\n return this;\n }\n\n build() {\n return new Car(this.engine, this.fuelTank, this.seats);\n }\n}\n\nlet truck = new CarBuilder()\n .addSeats(8)\n .addEngine('v12')\n .addFuelTank('200liters')\n .build();\n\nlet sedan = new CarBuilder()\n .addSeats(4)\n .addEngine('v6')\n .addFuelTank('100liters')\n .build();Factory Method Pattern, its similar to abstract factory method but has some subtle differences. In Abstract factory\npattern it creates Factories & Sub Factories depending on the type. (which i think is a little bit verbose) but Factory\nmethod is pretty straight forward it has only one factory.
\nDOM API's document.createElement method is a Factory method. which creates different type of HTML elements depending\non the passed type.
\n\n\n
class Document {\n render() {\n return null;\n }\n}\nclass Div extends Document {\n render() {\n return '<div />';\n }\n}\nclass Section extends Document {\n render() {\n return '<section />';\n }\n}\nclass DOMFactory {\n createElement(type) {\n switch (type) {\n case 'div':\n return new Div();\n case 'section':\n return new Section();\n default:\n break;\n }\n }\n}\n\nlet domFactory = new DOMFactory();\nlet div = domFactory.createElement('div');\nlet section = domFactory.createElement('section');Singleton design pattern is a creational design pattern that ensures that a class will only have one instance.
\nA good real world analogy for singleton is Government, a country can only have one government regardless of how many\nperson it consists of it be always titled as \"Government of {Country}\"
\n\n\n\n
class Singleton {\n static instance = new Singleton();\n static getInstance() {\n return this.instance;\n }\n\n showMessage() {\n console.log('Hello singleton');\n }\n}\n\nlet instance1 = Singleton.getInstance();\nlet instance2 = Singleton.getInstance();\nconsole.log(instance1 === instance2); // true\n\ninstance2.showMessage();Starting Structural Design Patterns
\nAdapter pattern is a structural design pattern which acts like a translator between two different interfaces/apis.
\nThis pattern could be useful in cases where you have two different APIs and you want an universal interface to handle\nthem both.
\nlet's take an example. suppose you are building a 2D Renderer for web which supports both WebGL & CanvasAPI you can make\nan universal rendering api and use adapter pattern to fill the gaps between them.
\n\n\n\n
class Python {\n print(msg: string) {\n return console.log(msg);\n }\n}\nclass Javascript {\n console(msg: string) {\n return console.log(msg);\n }\n}\n\nclass LoggerAdapter {\n adapter: any;\n constructor(type: string) {\n if (type === 'py') {\n this.adapter = new Python();\n } else if (type === 'js') {\n this.adapter = new Javascript();\n }\n }\n\n log(type: string, msg: string) {\n if (type === 'py') {\n this.adapter.print(msg);\n } else if (type === 'js') {\n this.adapter.console(msg);\n }\n }\n}\n\nclass Logger {\n adapter: any;\n log(type: string, msg: string) {\n this.adapter = new LoggerAdapter(type);\n this.adapter.log(type, msg);\n }\n}\n\nconst logger = new Logger();\n\nlogger.log('js', 'Hello world js');\nlogger.log('py', 'Hello world py');\"\"Decouple an abstraction from its implementation so that the two can vary independently\"\" what?
\nWell, it's confusing but it's interesting to see how useful this pattern could be.
\nBasically Bridge pattern allows us to separate the platform depended logic from platform independent logic.
\nThis could be useful for building User Interfaces where you want to make different views depending on different\nresources and doing that in traditional manner will force you to implement each and every view and their resource\nimplementation separately and will exponentially grow the number of complex coupled classes.
\nbut with bridge we can solve this issue by having a Uniform Resource Interface to talk with an abstract view class.
\n\n\n
interface IResource {\n title: () => string;\n body: () => string;\n link: () => string;\n image: () => string;\n}\n\nabstract class View {\n resource: IResource;\n constructor(resource: IResource) {\n this.resource = resource;\n }\n\n render(): string {\n return '';\n }\n}\n\nclass DetailedView extends View {\n render() {\n return `\n <div>\n <h2>${this.resource.title()}</h2>\n <img src=\"${this.resource.image()}\" /> \n <div>${this.resource.body()}</div>\n <a href=\"${this.resource.link()}\">readmore</a>\n </div>\n `;\n }\n}\nclass MinimalView extends View {\n render() {\n return `\n <div>\n <h2>${this.resource.title()}</h2>\n <a href=\"${this.resource.link()}\">readmore</a>\n </div>\n `;\n }\n}\n\nclass ArtistResource implements IResource {\n artist: any;\n constructor(artist: any) {\n this.artist = artist;\n }\n\n title() {\n return this.artist.name;\n }\n body() {\n return this.artist.bio;\n }\n image() {\n return this.artist.image;\n }\n link() {\n return this.artist.slug;\n }\n}\n\nclass SongResource implements IResource {\n song: any;\n constructor(song: any) {\n this.song = song;\n }\n\n title() {\n return this.song.name;\n }\n body() {\n return this.song.lyrics;\n }\n image() {\n return this.song.coverImage;\n }\n link() {\n return this.song.spotifyLink;\n }\n}\n\nconst artist = new ArtistResource({\n name: 'Anurag',\n bio: '404 not found',\n image: '/img/mypic.png',\n slug: '/u/anuraghazra',\n});\nconst song = new SongResource({\n name: 'Cant belive i can fly',\n lyrics: 'la la la la la',\n coverImage: '/img/cover.png',\n spotifyLink: '/s/song/132894',\n});\n\nconst artist_detail_view = new DetailedView(artist);\nconst artist_minimal_view = new MinimalView(artist);\n\nconst song_detail_view = new DetailedView(song);\nconst song_minimal_view = new MinimalView(song);\n\nconsole.log(artist_detail_view.render());\nconsole.log(song_detail_view.render());\nconsole.log(artist_minimal_view.render());\nconsole.log(song_minimal_view.render());Composite patterns allows us to compose objects which have hierarchical tree structure.
\nNice use cases of this pattern i can see is that you can easily make composable Layering & Grouping System, like\nphotoshop where you have a Layer() class you'll push Circle/Shape classes to the Layer and those shapes will get\nrelatively positioned and parented to that Layer.
\n\nconst rootLayer = new Layer('rootlayer');\nconst shapesLayer = new Layer('my layer');\nconst circle = new Shape(100, 100, 'red');\nconst box = new Shape(200, 100, 'red');\n\nlayer.add(circle);\nlayer.add(box);\nrootLayer.add(shapesLayer);\n\n\n
As you can see i have a FileNode, FolderNode if i were to implement this without composite pattern then i have to do\nextra checks to see if the type of the passed component is Folder and then recursively go through the childs and make\nthe whole tree.
\ninterface Component {\n remove?: (c: Component) => void;\n add?: (c: Component) => void;\n ls: () => string;\n}\n\nclass FolderNode implements Component {\n name: string;\n childrens: Component[];\n constructor(name: string) {\n this.name = name;\n this.childrens = [];\n }\n\n add(component: Component) {\n this.childrens.push(component);\n }\n\n remove(component: Component) {\n this.childrens = this.childrens.filter((c: Component) => c !== component);\n }\n\n ls() {\n let str = '\\n---' + this.name;\n this.childrens.forEach(child => {\n str += child.ls();\n });\n return str;\n }\n}\n\nclass FileNode implements Component {\n name: string;\n constructor(name: string) {\n this.name = '\\n------' + name;\n }\n\n ls() {\n return this.name;\n }\n}\n\nlet root = new FolderNode('root');\nlet src = new FolderNode('src');\nlet lib = new FolderNode('lib');\n\nlet jsFile = new FileNode('app.js');\nlet htmlFile = new FileNode('index.html');\nlet cssFile = new FileNode('style.css');\nlet mainFile = new FileNode('index.js');\n\nsrc.add(jsFile);\nsrc.add(htmlFile);\nsrc.add(cssFile);\nlib.add(mainFile);\n\nroot.add(src);\nroot.add(lib);\n\nconsole.log(root.ls());Decorator pattern allows us to enhance any class/object with extra behaviour without having to define any subclasses. I\nreally like the flexibility and composability powers which decorators provide me.
\nDecorator pattern is extremely useful and we have already used it in many places. Angular devs uses @Decorator syntax\nvery often. and React also make use of HigherOrder Functions (decorators), and libraries like MobX take advantage of\ndecorator patterns very cleverly.
\nJavascript will also have native @Decorators support some point in future the @Decorator proposal is right now on 'Stage\n2' so we might see some changes, i'm excited for it. but we can use typescript/babel to compile down those to todays js and use them right now.
\n\n\n\n
// simplified example\nfunction loggerDecorator(wrapped) {\n return function(...args) {\n console.log('******');\n console.log(wrapped.apply(this, args));\n console.log('******');\n };\n}\nfunction mapper(arr: any[], add: number) {\n return arr.map(i => i + add);\n}\n\nloggerDecorator(mapper)([1, 2, 3], 10);Facade pattern provides a consistent and unified API for any complicated API/Subsystem, making it easier to use for the\nclient.
\nIt basically works as a bootstrapper where it abstracts away all the complicated setups and provides a straight forward\nsimple interface.
\nExample is a little big so check it out on github
\nProxy is an object which works as a placeholder or substitute to any other object. proxy provides a similar interface to\noriginal object but extends the behaviour of how the object will react to changes.
\nThere are mainly 5 types of proxies.
\n▶️ Remote proxy acts as a translator between two remote origins and you can do stuff like logging the requests.
\n▶️ Cache proxy improves performance by caching any long running operation's results and serving the cached results\ninstead of request the data every time from the original source.
\n▶️ Virtual proxy object is a default placeholder proxy that can be lazily initiated, we can think of it as a skeleton\nobject which acts as the original object until the data loads.
\n▶️ Protection proxies mainly acts as a authentication layer for the original object. restricting unauthorized access to\nthe object.
\n▶️ Smart proxies adds extra behaviours to the original object, for example sending the data to any third-party API or\nlogging the data
\n// EXAMPLE OF PROTECTION PROXY\ninterface IServer {\n request(url: string): void;\n}\nclass Server implements IServer {\n request(url: string) {\n console.log('------');\n console.log('loading: ', url);\n console.log('completed: ', url);\n console.log('------');\n }\n}\n\nclass ProtectedServer implements IServer {\n api: IServer;\n bannedWebsites: string[];\n constructor() {\n this.api = new Server();\n this.bannedWebsites = ['https://fakesite.com', 'https://spamming.com', 'https://harmfulsiteyoushouldvisit.com'];\n }\n request(url: string) {\n if (this.bannedWebsites.includes(url)) {\n console.log('------');\n console.log('BANNED: ', url);\n console.log('------');\n } else {\n this.api.request(url);\n }\n }\n}\n\nconst server = new ProtectedServer();\nconsole.log('EXAMPLE-1 Protected Proxy');\nserver.request('https://google.com');\nserver.request('https://fakesite.com');\nserver.request('https://facebook.com');Starting Behavioural Design Pattern
\nCoR is a behavioural design pattern which we know of as middlewares. CoR lets us delegate the individual logic as a\nhandler and passing it onto the next handler.
\nA good real world analogy would be call centers or tech support channels.. when you call them, firstly you are prompted\nwith an automated voice asking you to do some steps in order to talk to a real person, then they pass your call to a\nreal person and if they can't help you they will again pass your call to a technician.
\nExpress.js heavily make use of CoR or Middleware pattern, it passed the next() handler to the next middleware performing\nsome checks and doing some operation in between.
\nCoR can be beneficial when you wanted to your logic to be reusable delegate the logic to multiple handlers. CoR also\nhelps minimizing the complexity of a tightly coupled system by making sure that every chunk of handler does some\nspecific work and passes the data to the next handler.
\n\n\n\n
// Chain of responsibility\nimport { consoleColor } from '../utils';\n\ninterface IHandler {\n addMiddleware(h: IHandler): IHandler;\n get(url: string, callback: (data: any) => void): void;\n}\n\nabstract class AbstractHandler implements IHandler {\n next: IHandler;\n addMiddleware(h: IHandler) {\n this.next = h;\n return this.next;\n }\n\n get(url: string, callback: (data: any) => void) {\n if (this.next) {\n return this.next.get(url, callback);\n }\n }\n}\n\nclass Auth extends AbstractHandler {\n isAuthenticated: boolean;\n constructor(username: string, password: string) {\n super();\n\n this.isAuthenticated = false;\n if (username === 'anuraghazra' && password === 'password123') {\n this.isAuthenticated = true;\n }\n }\n\n get(url: string, callback: (data: any) => void) {\n if (this.isAuthenticated) {\n return super.get(url, callback);\n } else {\n throw new Error('Not Authorized');\n }\n }\n}\n\nclass Logger extends AbstractHandler {\n get(url: string, callback: (data: any) => void) {\n consoleColor('green', '/GET Request to: ', url);\n return super.get(url, callback);\n }\n}\n\nclass Route extends AbstractHandler {\n url: string;\n URLMaps: {};\n constructor() {\n super();\n this.URLMaps = {\n '/api/todos': [{ title: 'hello' }, { title: 'world' }],\n '/api/random': Math.random(),\n };\n }\n\n get(url: string, callback: (data: any) => void) {\n super.get(url, callback);\n\n if (this.URLMaps.hasOwnProperty(url)) {\n callback(this.URLMaps[url]);\n }\n }\n}\n\nconst route = new Route();\nroute.addMiddleware(new Auth('anuraghazra', 'password123')).addMiddleware(new Logger());\n\nroute.get('/api/todos', data => {\n consoleColor('blue', JSON.stringify({ data }, null, 2));\n});\nroute.get('/api/random', data => {\n console.log(data);\n});Command pattern is a behavioural design pattern which lets us decouple the business logic from the client\nimplementation.
\nThink of it like when you go to a restaurant you, call the waiter and command him to place your order and waiter passes\nthat command to the chief, and after chief completed the order it gets back to you.
\nCommand pattern also lets you do undo and redo operations. Suppose you are making a text editor and you wanted to\nimplement undo, redo feature, it is can advantageous. And Command pattern also provides a nice interface to implement\nmodular GUI Actions allowing us to seperate the UI Layer from the logic of the code.
\nTraditionally if you have a CopyText feature, you might face scenarios like when you want to allow users to trigger that\nCopyText function from the ContextMenu and the Toolbar both, in this scenario Command Pattern can be very useful.
\ninterface ICommand {\n undo?(payload?: any): any;\n execute(payload?: any): any;\n}\n\nabstract class Command implements ICommand {\n calc: Calculator;\n constructor(calc?: Calculator) {\n this.calc = calc;\n }\n execute() {}\n}\n\nclass Calculator {\n currentValue: number;\n history: CommandHistory;\n constructor() {\n this.history = new CommandHistory();\n this.currentValue = 0;\n }\n\n getValue(): number {\n return this.currentValue;\n }\n\n execute(command: ICommand) {\n this.currentValue = command.execute(this.currentValue);\n this.history.add(command);\n }\n\n undo() {\n let lastCommand = this.history.remove();\n if (lastCommand) {\n this.currentValue = lastCommand.undo(this.currentValue);\n }\n }\n}\n\nclass CommandHistory {\n commands: ICommand[];\n constructor() {\n this.commands = [];\n }\n\n add(command: ICommand) {\n this.commands.push(command);\n }\n\n remove() {\n return this.commands.pop();\n }\n}\n\nclass AddCommand {\n value: number;\n constructor(value: number) {\n this.value = value;\n }\n execute(value: number) {\n return value + this.value;\n }\n undo(value: number) {\n return value - this.value;\n }\n}\n\nconst calc = new Calculator();\ncalc.execute(new AddCommand(50));\ncalc.undo(); // undo last commandIterator pattern is a behavioural design pattern which lets us traverse any complex data structure without exposing the\nunderlying implementation to the client.
\nWe can traverse graphs, lists, trees with iterator pattern easily. Javascript internally uses Iterator Protocol to\nimplement [...spread] spread operators and loops.
\ninterface IIterator {\n next(): any;\n hasMore(): any;\n}\n\ninterface ICounter {\n getIterator(): IIterator;\n}\n\nclass Counter implements ICounter {\n collection: any;\n constructor(data: any) {\n this.collection = data;\n }\n getIterator() {\n return new CounterIterator(this.collection);\n }\n}\n\nclass CounterIterator implements IIterator {\n current: number;\n collection: any;\n constructor(data: any) {\n this.collection = data;\n this.current = 0;\n }\n\n next() {\n return this.collection[this.current++];\n }\n\n prev() {\n return this.collection[this.current - 1];\n }\n\n hasMore() {\n return this.collection.length > this.current;\n }\n}\n\nlet iterator = new Counter([1, 2, 3, 4, 5]).getIterator();\nwhile (iterator.hasMore()) {\n console.log(iterator.next());\n}Mediator design is a behavioural design pattern which determines how set of objects will interact with each other.\nmediator pattern encourages loose coupling between components because it prevents objects from directly referencing each\nother. thus reducing the overall complexity.
\nMediator acts as an middle-man between different objects and all other objects will communicate through the mediator\nonly.
\nA nice real world analogy would be Air Traffic Controller. While landing and taking off airplanes does not talk to each\nother directly instead they talk to the air traffic controllers to get information about other airplanes and the control\ntower tell them when to land/takeoff.
\nI think this pattern has some use cases, for example when building ChatRooms you can implement mediator pattern to\nsimplify the relation between different members of the chatroom and send them messages though the Mediator.
\nYou can also use Mediator pattern as a global event manager in front end applications where components talk to each\nother by the mediator instead of passing callbacks/props.
\n\n\n\n
// mediator pattern\nimport { consoleColor } from '../utils';\n\ninterface IMediator {\n sendMessage(msg: string, from: any, to?: any): void;\n}\n\nclass Chatroom implements IMediator {\n members: { [x: string]: Member };\n constructor() {\n this.members = {};\n }\n\n addMember(member: Member) {\n member.chatroom = this;\n this.members[member.name] = member;\n }\n\n sendMessage(msg: string, from: Member, to?: Member) {\n Object.keys(this.members).forEach(name => {\n if (!to && name !== from.name) {\n this.members[name].receive(msg, from);\n return;\n }\n if (to && name == to.name) {\n this.members[name].receive(msg, from);\n }\n });\n }\n}\n\nclass Member {\n name: string;\n chatroom: Chatroom;\n constructor(name: string) {\n this.name = name;\n this.chatroom = null;\n }\n\n send(msg: string, to?: any) {\n this.chatroom.sendMessage(msg, this, to);\n }\n\n receive(msg: string, from: Member) {\n consoleColor('magenta', `-------`);\n consoleColor('cyan', `${from.name} says to ${this.name} : `);\n consoleColor('green', `${msg}`);\n consoleColor('magenta', `-------`);\n }\n}\n\nconst chatroom = new Chatroom();\n\nlet anurag = new Member('Anurag');\nlet hitman = new Member('hitman');\nlet jonathan = new Member('John Wick');\nchatroom.addMember(anurag);\nchatroom.addMember(hitman);\nchatroom.addMember(jonathan);\n\nanurag.send(\"I'm more dangerous than you hitman\");\nhitman.send('Sorry brother forgive me! pls', anurag);\njonathan.send('Hey hey hey hitman, nerver ever mess with Anurag', hitman);Observer design pattern is a behavioural design pattern which is a subscription system which notifies multiple objects\nabout any changes to the object they are observing.
\n▶️ The cool thing about observer pattern is that it decouples the State from the actual business logic. in terms of UIs\nyou can separate the State from the actual rendering of the UI and if that State updates the UI will automatically react\nto it.
\nSuppose you have a some Todos in your state you can decouple the data from the Ui and implement the render logic\nentirely differently. You can have a DOMRenderer and a ConsoleRenderer and both will react and update to the changes\nmade to the Todos. Heres a good example https://github.com/anuraghazra/VanillaMVC
\nYou can compare Observer pattern with daily newspaper subscriptions, If you subscribe to any newspaper you don't need to\ngo to the store everyday and get the newspaper instead the Publisher sends the newspaper to your home.
\nAnother analogy would be Youtube, well you might know pretty well that subscribing to youtube channels means you will\nget notification about new videos. Observer pattern also works the same. you as a user will subscribe to events you\nchoose to get notifications.
\nObserver pattern has lot of use cases. (a lot) Vuejs's Reactivity system relies on Observer pattern. The whole idea of\nRxJs is based upon observers. MobX also uses Observer design pattern effectively.
\nFrom User Interfaces to Data Reactivity, Observer pattern is really handy when some changes/events in a particular\nobject has to be reflected on other objects
\n\n\n\n
import { consoleColor } from '../utils';\n\ninterface IPublisher {\n addSubscriber(subscriber: any): void;\n removeSubscriber(subscriber: any): void;\n notifyObservers(): void;\n}\ninterface IObserver {\n notify(payload: any): void;\n}\n\nclass Publisher implements IPublisher {\n subscribers: IObserver[];\n state: any;\n constructor(state: any = {}) {\n this.subscribers = [];\n this.state = state;\n }\n\n addSubscriber(subscriber: IObserver) {\n if (this.subscribers.includes(subscriber)) return;\n this.subscribers.push(subscriber);\n }\n\n removeSubscriber(subscriber: IObserver) {\n if (!this.subscribers.includes(subscriber)) return;\n let index = this.subscribers.indexOf(subscriber);\n this.subscribers.splice(index, 1);\n }\n\n notifyObservers() {\n this.subscribers.forEach(subs => {\n subs.notify(this.state);\n });\n }\n\n setState(newState: any) {\n this.state = newState;\n this.notifyObservers();\n }\n}\n\nclass UserInterface implements IObserver {\n renderTodos(todos) {\n console.clear();\n todos.forEach(todo => {\n consoleColor('cyan', '-----');\n consoleColor(todo.isCompleted ? 'green' : 'red', `${todo.title} ${todo.isCompleted ? '[DONE]' : '[PENDING]'}`);\n consoleColor('cyan', '-----');\n });\n }\n\n notify(state: any) {\n this.renderTodos(state.todos);\n }\n}\n\nconst store = new Publisher({\n todos: [\n { title: 'hello', isCompleted: false, id: 1 },\n { title: 'world', isCompleted: false, id: 2 },\n ],\n});\n\nconst userInterface = new UserInterface();\nstore.addSubscriber(userInterface);\n\n// add todo\nstore.setState({\n todos: [...store.state.todos, { title: 'new item', id: Math.random() }],\n});\n\n// remove todo\nstore.setState({\n todos: store.state.todos.filter(t => t.id !== 2),\n});State pattern is a behavioural design pattern which lets objects change its behaviour based on its internal state.
\nIf you wanted to see the code, i have three examples on state-pattern in my github repo:\nhttps://github.com/anuraghazra/design-patterns-everyday
\n▶️ State pattern can be correlated with State-Machines where at certain point of time an application can only be in one\nstate or in a limited finite number of states.
\nWhere State-Machines heavily relays on if statements and switch cases which leads to Complex logic and unmaintainable\ncode when codebase gets larger. State pattern changes behaviour methods based on the current state.
\nSuppose you have a Music Player and that music player has 2 buttons \"UP\" & \"DOWN\"
\nA good real world use case would be a any drawing app / text editor or anything where you have some class which changes\nits behaviour based on some state.
\nfor example: if are building a drawing app the app will have a pain brush tool which would draw in different color/size\nbased on the selected color/size.
\nAnother example would be text editor, where you have a class for writing the text on screen but depending on the\nUppercase/bold/lowercase buttons you write appropriate character to the screen
\n\n\n\n
/* SIMPLE TOGGLE */\ninterface IToggleState {\n toggle(state: IToggleState): void;\n}\n\nclass ToggleContext {\n currentState: any;\n constructor() {\n this.currentState = new Off();\n }\n\n setState(state: IToggleState) {\n this.currentState = state;\n }\n\n toggle() {\n this.currentState.toggle(this);\n }\n}\n\nclass Off implements IToggleState {\n toggle(ctx: ToggleContext) {\n console.log('OFF');\n ctx.setState(new On());\n }\n}\nclass On implements IToggleState {\n toggle(ctx: ToggleContext) {\n console.log('ON');\n ctx.setState(new Off());\n }\n}\n\nlet button = new ToggleContext();\nbutton.toggle();\nbutton.toggle();Strategy design pattern is behavioural design pattern which lets us define different algorithms for doing a particular\naction and interchange them as we wish. basically means you can switch between different types of behaviour and\nimplementation.
\nStrategy design pattern is very similar to state design pattern. strategy pattern is an extension to state pattern, but\nstrategy pattern completely makes the subclasses independent from each other.
\nI think a good real world analogy would be a match of football. the coach (context) decides a
\nstrategy every situation the game flows through and switch between them depending on the situation. for example if the\nopposition is playing defensive then coach changes the strategy to playing aggressive. and when the team is leading 1\ngoal coach changes the strategy to semi-defensive.
\nIf you every used passportjs then you already used Strategy design pattern. passportjs uses strategy pattern to easily\nchange/add new Authentication providers and the system becomes more flexible to use and extend on.
\n\n\n\n
// Strategy pattern\ninterface IStrategy {\n authenticate(...args: any): any;\n}\n\nclass Authenticator {\n strategy: any;\n constructor() {\n this.strategy = null;\n }\n\n setStrategy(strategy: any) {\n this.strategy = strategy;\n }\n\n authenticate(...args: any) {\n if (!this.strategy) {\n console.log('No Authentication strategy provided');\n return;\n }\n return this.strategy.authenticate(...args);\n }\n}\n\nclass GoogleStrategy implements IStrategy {\n authenticate(googleToken: string) {\n if (googleToken !== '12345') {\n console.log('Invalid Google User');\n return;\n }\n console.log('Authenticated with Google');\n }\n}\n\nclass LocalStrategy implements IStrategy {\n authenticate(username: string, password: string) {\n if (username !== 'johnwick' && password !== 'gunslotsofguns') {\n console.log('Invalid user. you are `Excommunicado`');\n return;\n }\n console.log('Authenticated as Baba Yaga');\n }\n}\n\nconst auth = new Authenticator();\n\nauth.setStrategy(new GoogleStrategy());\nauth.authenticate('invalidpass');\n\nauth.setStrategy(new GoogleStrategy());\nauth.authenticate('12345');\n\nauth.setStrategy(new LocalStrategy());\nauth.authenticate('anurag', '12345');\n\nauth.setStrategy(new LocalStrategy());\nauth.authenticate('johnwick', 'gunslotsofguns');Template method is a behavioural design pattern which defines skeleton of an algorithm in a step by step manner and lets\nsubclasses override them.
\nBasically what template method does is that it requires you to split an algorithm into a smaller chunks and make\nseparate methods for them, and then call each of the methods sequentially in a series. that way you can override any\nstep of an algorithm in a subclass.
\nA good real world analogy would be the concept of house construction, while making a house it requires some steps such\nas building the roof, floor, walls electricity supply etc etc. and the client (or the owner) can customize these\ncomponents and get different type of house.
\nTemplate method is widely used in frameworks, lets take Reactjs
\nReact's Class Component is a implements template method where it has placeholder methods of componentDidMount,\ncomponentWillUnmount etc etc and the client will override and customize these methods as per their needs.
\nBtw fun fact, these kind of inversion of control is called \"the Hollywood principle\" (\"don't call us, we'll call you\".)
\n// template method\nimport fs from 'fs';\n\nabstract class DataParser {\n data: string;\n out: any;\n constructor() {\n this.data = '';\n this.out = null;\n }\n\n parse(pathUrl: string) {\n this.readFile(pathUrl);\n this.doParsing();\n this.postCalculations();\n this.printData();\n }\n\n readFile(pathUrl: string) {\n this.data = fs.readFileSync(pathUrl, 'utf8');\n }\n\n doParsing() {}\n postCalculations() {}\n printData() {\n console.log(this.out);\n }\n}\n\nclass DateParser extends DataParser {\n doParsing() {\n let dateRegx = /(0?[1-9]|[12][0-9]|3[01])[\\/\\-](0?[1-9]|1[012])[\\/\\-]\\d{4}/gim;\n this.out = this.data.match(dateRegx);\n }\n}\n\nclass CSVParser extends DataParser {\n doParsing() {\n this.out = this.data.split(',');\n }\n}\n\nclass MarkupParser extends DataParser {\n doParsing() {\n this.out = this.data.match(/<\\w+>.*<\\/\\w+>/gim);\n }\n\n postCalculations() {\n this.out = this.out.reverse();\n }\n}\n\nconst dataUrl = '../../behavioral/data.csv';\n\nnew DateParser().parse(dataUrl);\nnew CSVParser().parse(dataUrl);\nnew MarkupParser().parse(dataUrl);Visitor design pattern is a behavioural design pattern which lets you define new operations/behaviours without changing\nthe classes.
\nA good real world analogy is given by refactoring.guru where it says imagine a insurance agent who is eager to get new\ncustomers, he will visit every building on the region and
\nVisitor pattern is very useful when it comes with extending existing behaviours without changing the base class.
\nIf you every wrote a GraphQL directive you've used visitor pattern.
\nGraphQL server exposes a \"SchemaDirectiveVisitor\" class which has methods like \"visitFieldDefinition\" & \"visitEnumValue\"\nit implements the visitor pattern to add extra behaviours to the schemas.
\nVisitor pattern is also really useful for modifying AST trees where you can visit every node and modify it one by one. i\nhave a example on my git repo: https://github.com/anuraghazra/design-patterns-everyday
\nYou can also implement visitor pattern to make Exporters as you can see on my example. i have a SVGExporter and\nCanvasCallsExporter.
\nCheck out the example on github
\nANNNDDD THATS IT! Phew! it was long.. i know you probably did not read it but thats ok, you can come back anytime\nwhen you are stuck with a specific design pattern or confused about it.
\nPersonally i feel like in web development world most useful patterns are:
\nLinks:
\n\nLearning Resources:
\n\nI hope you find this post useful! Thanks for reading folks.
","timeToRead":27,"id":"18223ce0-1b70-5ca1-a74b-6a3adb2f033e","frontmatter":{"date":"May 20, 2020","title":"Design Patterns Everyday"}}},"pageContext":{"slug":"/blog/design-patterns-everyday"}},"staticQueryHashes":["1033876704","3435786681","550521386"]}