The Proxy pattern

The proxy pattern is a software design pattern.

It is basically, in its simplest form, an interface to something else.

But let's take a look at what it is and how you could use it!

🧵👇🏻
1⃣ What is it?

A Proxy is a wrapper (object), that wraps another object.

Imagine it like a container that looks exactly like the object it wraps, behaves nearly the same, but may add some additional functionality.

You can imagine it, visually, like shown below.
If you need another example:

Imagine a wetsuit. It's a thin layer above your body, keeps the shape of your body, but adds the ability to keep you dry inside!

👇🏻
2⃣ What is it good for?

Proxying is a great pattern to use when you want to add additional functionality to an object, e.g.!

A very simple use case would be an access level audit log, which fires every time you access or set a property on an object or call a method on it.   property: "foo",   method: function () {     ret
Another, more complex use-case, is the usage of proxy objects in object relational mappers (short: ORMs).

You sometimes get proxy objects instead of plain objects when you fetch data.

This enables the frameworks to fetch only some of the data, and add lazy fetch functionality.
Although you might have a user object at hand, which has a relationship to multiple posts, some ORMs would only fetch the user.

As soon as you access a post or a collection of posts, the proxy fires another fetch and only then returns the real nested object!

👇🏻
3⃣ Language-level support in JavaScript

Copying each and every property, and method, and...and...and of an object may seem like way too much work to do manually, and you are right!

This is why many languages, including JavaScript have added meta programming capabilities...
...to their standard libs and runtimes.

The simplest form of a proxy in JavaScript, one that simply forwards everything to the original object, without adding any functionality, can be seen below.

The second argument here is an empty handler object. const obj = {   property: "foo",   method: functio
If you want to recreate the audit logging as a Proxy, you can see a very simplified version of how you could do it below.

The properties get and set within the handler object are so-called traps.

They fire whenever a certain action on the object is registered. const obj = {   property: "foo",   method: functio
In this case, 'get' fires when a property is accessed, and 'set' fires when a property is set on the object.

There are more traps, and you can, if you're interested, find out more about them here:

developer.mozilla.org/en-US/docs/Web…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Oliver Jumpertz

Oliver Jumpertz Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @oliverjumpertz

27 Nov
DI - Dependency Injection

Dependency injection is a technique in which an object receives other objects it depends on.

It is actually one form of the broader technique inversion of control.

🧵👇🏻
1⃣ What is it?

Dependency injection is a technique where every other object (service) an object (client) depends on is injected from the outside.

So instead of simply instantiating everything on its own, a class relies on it being passed in from the outside.
You can also view it this way:

Imagine your favorite RPG character could only wear the equipment they started with. No way to change the equipment or the look of your character's equipment from the outside.

Would be boring and inflexible, wouldn't it? Image
Read 13 tweets
26 Nov
The Singleton Pattern

The singleton pattern is a software design pattern.

You can also call it the Highlander Principle: There can only be one!

But don't expect epic fights with swords and beheadings, that's only for the movie(s).

🧵👇🏻
1⃣ What is it?

As stated before, the singleton pattern is a software design pattern.

It restricts the instantiation of a class or a certain object to a single instance.

The pattern and its name are actually derived from the mathematical concept of a singleton.
In other words:

If you have a class A and make it a singleton, there can only be exactly none or exactly one instance per application.

Why none?

Because sometimes those singletons are also instantiated lazily to save resources, in case they are never needed!

👇🏻 Image
Read 10 tweets
24 Nov
The Iterator Pattern

The iterator pattern is a design pattern which can be used to decouple algorithms from containers.

Let's take a look into what it actually is, how to apply it, and which problems it solves!

🧵👇
1⃣ What problems does it solve?

✅ The elements of an aggregate object should be accessed and traversed without exposing its representation (underlying data structure)

✅ New traversal operations should be defined for an aggregate object without changing its interface
Those two points may sound a little complicated, but you can view it this way:

If you define access and traversal operations within an object's interface (its methods viewable and usable from the outside), it becomes inflexible.
Read 14 tweets
22 Nov
Although I am not a data scientist by any means, I was recently asked what knowledge of math someone would need to be able to efficiently get into the field.

Well, I researched a little and came up with the following course track, starting with the basics.

🧵👇
Calculus 1 will cover a lot of the basics, relevant especially to optimization problems which are quite common in data science.

khanacademy.org/math/calculus-1
Calculus 2 will go even deeper and cover topics such as integration techniques and differential equations.

Especially integrals are pretty important for probability distributions and hypothesis testing!

khanacademy.org/math/calculus-2
Read 7 tweets
21 Nov
DIP - The Dependency Inversion Principle

The Dependency Inversion Principle is a part of SOLID, a mnemonic acronym which bundles a total of 5 design principles.

It is often associated with clean code.

But what exactly is it, is it important to you, should you even care?

🧵👇
1⃣ What does it state?

It states:

Modules that encapsulate high-level policy should not depend upon modules that implement details. Rather, both kinds of modules should depend upon abstractions.

This may sound a little complicated, but you can break it up, as follows:
1. High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces).

2. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
Read 17 tweets
20 Nov
ISP - The Interface Segregation Principle

The Interface Segregation Principle is part of SOLID, a mnemonic acronym which bundles a total of 5 design principles.

It is often associated with clean code.

But what exactly is it, is it important to you, should you even care?

🧵👇
1⃣ What does it state?

The ISP sets a pretty simple statement:

"No client should be forced to depend on methods it does not use."

ISP applied to the extreme will result in single method interfaces, also called role interfaces.
You can take a look at the following example to get an idea of how the ISP can be violated in one way (this time it's in TypeScript): interface ReportService {  ...
Read 14 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!