I’d spend a couple of hours studying, planning, and understanding a problem, just to solve it in minutes.

The Time Machine

What If I told you that, there is a ball of crystal that when u do strange and funny hand moves saying non-sense in front of it and suddenly a cloud of (usually) purple floats magically from below it to say what bugs are you going to face early on, how bad your ad-hoc design inside the code is, how miserable the company is going to be... once you get to the 3rd month and how the first 3 months are going to be so happy and proudful, only to find people waiting for you to move this button from here to there? (replace here and there with a login wall and you will automatically get the point ;))

What am talking about is not really Disney (whispers: I was indeed imagining them)

What am talking about is...

Draw.io!

or your sketchbook, or your iPad where u can draw

but since up there we mentioned that Software Design is an art, so we should get sketchin'!

Let's tackle down an Authentication Flow that does the following

It integrates with our BE through, Email and Password Phone and Password Continue as a guest FaceID and QR Code Scanning Facebook, Twitter, Pinterest, LinkedIn, Github, Apple, Google, Reddit, and every authentication provider there is to integrate with

Of course, if you had something required like this, you should leave the job since neither r u a bank to be this secure, nor are you a god damn hub of getting people together from all around the world, what you are right now is someone who is about to learn how the hell do we detect which design pattern to use for this task and how can you assign 3 engineers (including urself of course) to finish it, in a timely manner of under... 3 days would be a good estimate I think (guess what, first 2 days are in the foundation, 0.85 days in the implementation and 0.15 days in testing what u did ;) (btw this is not TDD, it would take shorter than this if it was TDD or BDD) (also BDD makes more sense in mobile)

If we go back to the reference of what we want to do basically, is one button may trigger something, another button may trigger a different flow, a 3rd one may trigger something completely different than the other 3

but it all boils down to one big funnel, which is...

Logging the user in!

What if I told you is what we are talking about is a game of strategies? which strategy will we use, to get the guy into our app in the quickest way possible?

Strategy Pattern: Did someone say Strategy Pattern?

Shout out to my Sensei right here, Abdoelrhman 🙌 for making it a possibility to learn that pattern 🙏

Let's start with the why by answering how many SOLID principles are done through this pattern in this use case?

but first, let's do that on a sketch, shall we?

Give those diagrams 2 looks, 1 quick look, another is deep and zoom into the annotations I wrote to clarify the bits and pieces

Tip: If you see this, you may find that this is just a piece of the puzzle, and that's exactly what is needed here, you don't have to draw the whole picture in 1 go, just a step by step, slow and steady wins the race (YAGNI, remember?)

Now, ask yourself, how can I do this and instead of worrying and letting your emotions get over you, build one now, you can get back to these if you want, but always remember, you are talking at a very high level now, no details are allowed, just pure simple rectangles and arrows that represent communications, ownership, responsibilities and a direction of where everything is going and how the data flows (regardless of whether u use delegates, callbacks, Observables, AnyPublisher or Subjects, or KVO, or just pure notifications (1 quick note here, do not reference the previous layer in a deeper layer, the deeper you go, the more independent you should be, and hence more reusable (or Modular)))

Did that? GREAT JOB! get yourself a cookie 🍪

now what if I tell you right now, absolutely right now, that if you want to open-source this whole thing, and have your name is written behind the largest authentication pod/package/library/framework that combines all of these and give the end-user (us programmers) just one method to use and that is "authenticate()" (am assuming usage of Promises here :P) then you can just take the whole authentication module, and put it on Github 😉, and whatever goes on Github goes on any future project for you to finish that 3 days task in... 3 mins? (an exaggeration, but unless you are a UI ninja known as the Yellow Flash, or UI is already built, then it may be doable)

Because it's modular

And being modular allows for being testable

So how will we test this?

Remember Liskov?

She said that a system may behave the same way if I replace one component with another

and since we want to test behavior, not syntax, which part of this diagram do you think we can replace with a fake/mock/stub (every part does something different but for sake of simplicity, just consider them all as one, and that none of them is going to call any backend of-what-so-ever)

So, in Unit Testing, let's fake that AuthProvider, and make it trigger certain behavior through fake flags and assertions thru spies