We need to praise code aesthetics more: amazing production quality, deep insights, real-world advanced examples, 0 bs. All been made single handedly by an independent small youtuber. Such a gem

Ohh fLiP dO yOur jOb

I have three rules for DRY 1: if the code has reason to change independently, just copy paste instead. 2: if I notice that a function has become aware of where it is being used, I know that I messed up. Signs of this is when parameters keep getting added. Usually those parameters contain words like skip or include. 3: don’t bother reusing trivial stuff Usually rule 2 is a result of not following rule 1.

In Haskell, dependency injection is the norm (as your Monads are implicitly given to monadic functions when called, and they can easily be replaced with compatible Monads). Since it's such an integral part of the language, having DI everywhere is no longer an issue, since the typing system is so beautiful. I program in Haskell, by the way.

So, for the testing, they are testing the actual uploading code with the fake encryption- so if that test fails, you know the uploading has an error, rather than just knowing that the error is in either uploading or encryption or the key. Then for the encryption test, using a fixed test key makes total sense- and then integration testing by uploading an encrypted file, but, with a fixed test key still. This makes total sense as a great way to test stuff.

Brother, you're like my go to for learning the how-tos of programming. Because of your teaching and memes i got a new job with higher salary. thanks Prime.

OOPERS when they discover function parameters, "THIS IS THE BEST PATTERN EVER!"

DRY is often misunderstood. The idea isn't to never repeat yourself, but to have all _information_ have a single source of truth. That is, you don't want to have to change some fact in several places since that will definitely come to haunt you. In the Pragmatic Programmers book they actually explicitly give an example of deliberate code repetition in case it represents different concepts/information. Just FYI :)

I agree, don't repeat yourself a lot (3-5 times is fine) and code first so that things work, then you can clean and optimize. once you start cleaning and tuning, you can write tests to be sure and stable, before that you don't need the tests too much. Greate video and great comments ;)

Strategy Pattern is one of the things that always seemed so obvious to me that I question the utility of giving it a name.

You know you've gone too far with Dependency Injection when you're struggling to find your concrete implementations.

15:55 This, so much this. One time a junior dev asked me at work about what my faviourite pattern was and I was just like: I don't know. I don't know the names of most patterns and principles. I am just asking myself what the clearest way is to tell my intend to the next person working on the project. How can I deliver that we have i.e. a few possible file types that need to be treated differently and how can I bake that into the type system. What is the most minimal solution for that. I know, a chain of if statements would also deliver the intend, but I don't know how to describe it better here

the only bad thing about dependency injection is that it breaks my "Go to Definition" as IDEs can't figure out which implementation you want to jump into so they take you to the interface .. pain

This is one of my favorite patterns for plug-in type systems. Turning DI into abstraction hell is a code smell.

Having had quite some dozens of juniors come and go, a good chunk of them try to think of the pattern before prototyping. Some of them have this mindset of "If I use a good pattern from the start, I won't need to rewrite anything". Then they come up with the most convoluted solutions to easy problems. That was before we had code review so thankfully things are way better now. I understand this line of thinking, and it makes sense on a logical level, but never on a pratical level. And yeah, I think 99% of the good readable and testable code are strategy patterns that spawned after a functional prototype.

The testing issue raised around 23:50 is something I run into a lot, especially with teams that are just starting out on their automated testing journeys. I have a simple rule: If that mock could conceivably be used in production (e.g. sqlite instead of postgres, a file directory instead of s3), then its a useful mock. If it would be worthless in production, its a worthless mock, and a worthless test, throw it away. For those, the only real way you can test them is to spin it up in docker compose or k3s and test it for real.

Mocking allows you to test the happy and the bad paths... So you can tell your mocked dependencies to return a bad result or a service outage or something from your result and handle that in the tests that way you know your code is going to handle everything properly...

"...comes down to two patterns: [builder] and [strategy]" - parsing library maintainers catching strays

New to the channel. This guy is so way over my head, it depresses me. There is just so much to know and understand.

All of these patterns that force you to write tons of classes to do anything and leave you bloated with Managers, Generators, Runners, Loaders, etc., only make sense for the person who writes them. In reality, they are extremely hard to debug, and all of this encapsulation makes it impossible to know what will happen without debugging at runtime. I started my career with Java and used all of these patterns. But then I grew up and stopped using any of them. Today, I just write a simple function, pass the parameters, and reduce all of the decision logic for using one strategy or another to "if" or "switch" statements. I only use classes in very specific cases for self-contained stuff. I almost never write the words "extends" or "implements" anymore, and my life is much better for it. :)

Over many videos now I have come to love Prime's responses of affection when being handrd sustenance from his wife.

some luv to the editor, 20vids a day is insane!!

This is one of the reasons why I hate OOP (not necessarily objects): all of the stupid names for simple things. "Dependency Injection" is just passing objects to procedures as a value. WHY DOES IT NEED A SILLY NAME LIKE THAT?!

I saw the original video and since then i refreshed your channel every few hours waiting for a reaction.❤

The downside is simply that you have no idea WTF is happening when you enter a new code base full of DI.

I learned a lot watching the video you're discussing, mostly things I didn't know how to do. But "how" it's done is to me, nice and clean. I believe I got to the video from a video talking about using composition rather than inheritance. So, both the "favor composition" and "use DI" were to me 👍👍. I appreciate your comments as well Prime. Thanks to all. Will investigate the strategy, builder, and factory patterns much more now.

The moment you defined `as const` as the "pointer to a constant", I immediately thought about trying the exact same experiment you did with `let`. Glad you covered that 10 seconds later.

Without being a big fan of using mocks for integration tests they make a lot of sense in the case that you do black integration testing and white unit testing. That way you can make sure that the units conform to the interface and the mock getting a lot of depth from those tests, then the integration tests can be very shallow and be very wide with minimal effort. This allows for great coverage at the cost of minimal brain power, you can then argue if that is worth or not.

My last BIG project was one based upon a DI framework (in Java). It was great. However, there were times developers created some spaghetti apps where they created DI apps that data could get lost in. I think they didn’t design or think out their app well. While “not my code”, I would often get called at midnight to fix it. The code from our group based upon this framework had very few problems (most were traced to 3rd party data providers). We would work as a group to talk through data paths in our app. Worked well.

I think the difference between strategy and adapter pattern is that strategy uses different interchangable components for different outputs / side effects and adapter uses different interchangable components, but we expect the result to be the same whatever implementation you use. I do think he showed us more adapter patterns than strategy by that definition, but it is a very fine line nonetheless.

You make it fun to learn the science behind code thanks man!

I loved that comment. Most of programming is using builder pattern and strategy pattern. I agree whole-heartedly

I cant imagine not using DI in C#, usage of factories like in Java is not required at all in C#, we can use a nice DI container like Autofac,Ninjact etc for Strategy pattern (multiple implementations of same Interface) and resolve them at runtime using a key. In .NET 8,keyed resolve is also supported bt default DI container.

The problem with DI and OOP (which DI isn't the only thing used) is that, it relies heavily on abstractions. You always cook something over some gigantic amount of some object that all are abstractions over abstractions.

Watching this video while eating is like eating with theprimagen and watching a computer science video together

You can't EQ out clipping. The closest you're getting to removing clipping is using something like the declip module in izotope rx, which luckily is pretty painless to use

Us FPers staring at the OO crowd for giving some fancy name to passing data as a function argument.

One thing I remember from somewhere is that *locality* is a key principle for code readability (as with all things in software, it's a principle, not something to overdo) and it seems DI really helps keep locality and so that's part of what helps keep it readable when it's used right.

In python, I usually have a default implementation of e.g. a Repo, that does exactly what it should do, and inject it. So the usual work of DI based usecases for clean arch become self-sustainable, and only while testing, I replace the dependency. I am not sure, why everyone shys away from happy path defaults. It makes it a lot easier to deal with, than having endless debates whether we should dependency inject this or that here or there, which is usually won by the guy who wants everything explicit, with ten interfaces, and quits the job right after everything has been refactored to this overexplicit mess.

Polymorphism is an OO contruct oft utilized in patterns. It is simply the ability for the caller to execute code without knowing the subclass implementation. That's it.

7:58 You can have a pointer to a constant, but you need to give the type implicitly because "as const" forces TS to infer a narrow type. let foo = { a: 5 } as const; gives foo the type {a : 5}, to which { a: 4 } is not assignable.

I got a DoorDash ad right after the Wifeagen brought him food. “You know… you can have your food delivered too…”

I am fully on board with Code Aesthetic with this one. I don't like it when people give simple things impressive names. It is indeed no "dependency injection", it is passing a stupid thing to a function and so is it not "strategy pattern", it is a literal stupid if statement

love the smug ass incorrect pointer assumption that you then fail to prove. really nice dude *chefs kiss*. confidence inspiring

The separation of logic and I/O is the ports and adapters or hexagonal architecture pattern and yes, it's very useful. But also it can be taken to an extreme and become a nightmare. Don't ask me how I know this 😅

This example uses dependency injection as a way to implement the strategy pattern, which does make sense to some degree (Was there a test verifying that the correct dependencies are injected in the production version? A pretty crucial part of the solution) But for the vast majority of code that I've seen, there is NO strategy - no alternate implementations of behaviour (in production code). It's just, the DbContext is injected into the UserRepository. The UserRepository is injected into the UserManager. The UserManager is injected into the UserController. And then each of these are tested independently with a ludicrous amount of mocking (I've seen implementations where the very thing to test had been mocked out). The hip bone's connected to the ...

Speaking as a 30-year C++ vet, you give great advice.

A lot of this can be dumbed down and distilled to this simple thought: Whenever you are implementing a functinality, always keep in mind "who's concern is this", e.g. Where the data will be stored, how the data will be scanned, and even WHAT the data is, is NOT a concern of the UploadRequest, so it SHOULDN'T KNOW anything about

In elixir there is pattern matching on function args. It removes all of the if/else and makes it duper easy to parametrize behavior... Uh i mean, "inject dependencies" (did I use the fancy words correctly? I need to impress the Jr devs while making them feel dumb for not understanding my big thoughts right away)

17:10 DRY is aspirational. Don't does necessarily mean never. Nice to hear this!

"This is stupid!" * proceeds to smack his lap ...is such comedic gold

TypeScript "as const" is *type narrowing*. I.e. narrow it to the most specific type possible. So `{a : 5}` is typed as `{a: number}`. but `{a: 5} as const` is typed as `{a: 5}`.

It's interesting to see how Slack programmers think and make solutions and all the high brow talk (to make it sound cool). Good video. I wouldn't have ever found or watched that guy's video.

0:43 Just starting out, that’s not what “dependency injection” was. That’s just delegation, or what you could call parameterized composition, or even just configuration. When “dependency injection” began to be discussed at all, it was about configuring code dependencies from outside of the call path, say via XML configuration files. That’s why it was called “injection”. “Delegation” and “configuration” are much older concepts. For example, if you have configurable service providers, that, in your call path, selects a service provider based on on a configuration property, that was not called “dependency injection”. For it to be called “injection”, the injector would replace runtime calls to a particular service, say described by an interface, with the desired implementation, with the original code being none the wiser. If DI is defined this way today, it seems like its proponents trying to grab ground that doesn’t belong to them. If you want to call it “dependency management”, have at it. But by trying to redefine “dependency injection” in this way, you’re trying to wave away why so many saner engineers thought DI was unworkable in the first place.

16:58 The proper phrase is actually "Avarice is the root of all evil". 🤓

"My code simply felt too direct and straightforward, so I added 7 layers of indirection and fragmented the code to make it harder to reason about control flow". That is literally this video, I really wish I never need to maintain any piece of code written by this guy (CodeAesthetic). Not a single thing he said in this video made sense, he complains that there are "too many code paths" (there aren't), but his solution doesn't actually reduce the paths, it just fragments the code so it's now harder to debug, since you now need to jump all over the place and probably look into multiple files to even figure out what's going on, control flow is no longer explicitly in the code, you now have to keep it all in your head, that is absolutely NOT easy to "reason about". The code could be much simpler, just use an union and a single switch statement, no need to even call any functions, it's not even a lot code (not that it would matter), and you can look at all possible paths in a single file, in a single function, super easy to debug. This factory nonsense is also completely unnecessary, just organize your data properly, there's no need to have multiple lists for separate services, all you need is one single list of "StorageParams" (which should be just an union), every company has a "StorageParams", that's it, there's no special code needed because all the data you need is literally right there.

You don't test a car by just going on the road, but you test the engine on a dyno, the tyres by checking the wear and slip in wet conditions, etc. You want to test thing individually to see where it goes wrong. Mocking and simulated environments can be convenient for this. But in general, testing to me is just taking the code that I already wrote to see if everything worked and saving it.

My advice is to always use DI even if you aren't using an IoC container; passing deps in through a constructor manually is still DI. Always pass your deps in through the constructors.

Fun fact - if you start your script with 'import this' you'll find python is fast enough in 90% of cases.

I think Dependency Injection is a solution to a problem that doesn't need to exist - also it's just a function pointer. And that OOP design patterns are usually sirenic: sounds useful but actually ends up being worse at both complexity, readability, maintainability and especially performance - and makes it easier to buy into the learned helplessness aspect of just integrating with yet another module/library to fix your problems without understanding them. And I've mostly found most of OOP's advantages are in small scale prototypes with problems that are very close to your comfort zone.

21:57 Yes, this! I try to split components by those who work with data and those who work with timing and DI is nice for that.

In the land of C: a struct type containing - an enum to switch on and a "union of struct types" for the parameters... Add in a test/mock type and its all good for unit tests. "What if someone passes the wrong parameter structure?" well, then you have personal and integration problems that compiler checks won't save you from. Abstract the APIs behind open,read/write close file interface a la Unix... What about the weird and wonderful things that can go wrong with each storage method? Generally "something went wrong" is important for control flow. "What went wrong?" that's a debug issue (and that is why Golang error handling works like it does). In my experience... code that properly handles something going wrong at any time, is rare enough... and using "what went wrong" in control flow is abused or only partially handled.

i mean. here's the thing. experts in anything know the exceptions to the rule. we teach DRY because it's a very valuable concept. it's more about don't cut and paste the same code all over the place, abstract it out, make it easy. i've been out of things for a while, but i never heard the Extreme folks saying DRY in relation to patterns, DRY means abstract out common code so you don't have to maintain and debug 10 separate instances of something that could be done once.

Whats your opinion on e2e testing mircroservices or approach? I'd like to use test containers for integration test but it's an uphill battle to get a sign off on it for the enterprise version. I do agree that mocking usually causes issues and you end up always finding bugs due to something external not working as expected. For e2e we had to build out a microservice to test all the other services which I'm not a fan of.

As a typescript developer (frontend) You won my like during the "as const" thing, that shit was great btw

"I am mustafa, and I am the code you be refactoring now........ damn, three times"

S3 the largest graveyard? Confluence was right there, though.

Dependency injection using the basic features of a programming language is great. But Java EE style dependency injection, which uses a zoo of annotations, plugins, and config files, is a nightmare that can easily make code unreadable. It forces you to rely on documentation for things that should be obvious. It creates major problems for a minor boost in comfort. Programmer: "So what is actually getting injected here? Where does this call actually go to?" IDE: "IDK, it's just here. Check the annotation I guess" Annotation: "I'm just a piece of text. Maybe copy-paste it and search THE ENTIRE CODEBASE" Codebase: "Na sorry nothing found lol. The config files to resolve the name used in the annotation are not in the project folder and maybe not even on your machine, I'm pulling half my sht off some web service."

"There's only one implementation of..." I know where this is going. @24:30 the sample test code can have multiple implementations - always happy path, always sad path, slow network, dropped network, etc

All programming is about reducing indentation, AKA SINGLE RESPONSIBILITY + DEPENDENCY INVERSION, AKA reducing cyclomatic complexity, AKA making code easy to test. The first step (following TDD dogma) is to write a test that asserts that your code does something, the second step is to make your code do something, the third step is to make all the things your code does simple, the fourth step is to compose those things in such a way that they do the original thing and the fifth step is to ensure that you're not doing too much work to make that composition happen. I don't follow TDD dogma, so I do the first step at the end, and test manually in-between.

Dry is bad when you refactored out code that actually wasnt the same and have to start adding multiple conditionals in it to gandle different use cases. This is especially annoying/hard if you pulled it out to a shared repo as you cant stop allowing the old pattern or else yoh may break other code.

Is he eating tangerines with bread slices? Absolute mad lad.

22:00 that's literally the entire concept behind languages like haskell- that's why you have pure functions that do your computation and then everything that interacts with the outside world happens through the io monad.

Mocking is wonderful to simulate failures upstream or downstream of the thing you want to test. It's also useful if the actual task is way too expensive or slow to run. Otherwise you are probably better off not mocking.

I don't use TS but one way I solved having multiple sets of parameters is to have a lookup object table. The class must be constructed with, for example the storage service to be used. Then the object map provides autocompletion for the rest of the parameters using JSDoc. I don't have types for the class but it is well documented and autocompletion is a chef kiss.

I don't use dependency injection as extensively. I use a mix of dependency injection and dependency requesting or dependency obtaining. DI is already explained here. DR or DO are similar but differ only on where the login for having the dependency is. In DR, the class/object knows who can provide the information and it requests that said object instance or just piece of data from that external entity. In DO, the class/object knows where the source of information is for something it requires to work. Although in enterprise they like to DI almost everything, I'm more the kind to just do a mix of the 3 depending on the context. I'm not that much of a fan of the only way being having code (mine or from a lib/framework) to fetch and provide the dependency to the class. Many times, that said class already knows where to get it and just gets it instead.

While doing Advent of Code (which I'll finish later...), I often deduplicated code that would only occur twice, but that's a bit contrived since you know that most of the code will overlap upfront.

I'll have to jump over infinite places to find the code that actually does the 1+1 that's the issue, it should never be first, DI and patterns should come later, and maybe never, if all you are doing is that 1+1, never do this.

23:14 Code Aesthetics literally explains what the point of all the mocking was, right before @ThePrimeTime pauses and says "I don't get the point of all this mocking". The point is to test the uploading service in isolation. Later on you test your encryption service in isolation. Later still you test your S3 storage service in isolation. The point is to make it easy to determine where any potential bug is. If you didn't isolate the services with mocks, and your test failed, now you have to go in and hunt down exactly where a bug is occuring. By isolating all the services, you know that when a test fails, the bug is ONLY in that tested code, and not in an upstream service.

For the person asking for a concrete example of DRY being bad. When you’re doing microservices, DRY leads to heaps of shared libraries and, holy cow, that was a hot steaming mess.

Chat so eager to admit their blatant refusal to learn and their propensity to copy and paste code

7:55 Noooo! It should actually be possible if foo is defined as type {a: number}. However the "as const" with type inference sets the type of foo to its strictest interpretation: let foo: {a: 5} = {a: 5} as const; so foo = {a: 6} is invalid, because 6 cannot be assigned to something of type 5, which is what the error message actually says.

Finally someone said it, DRY only if it actually repeats, not just randomly happens to be the same in two places. I only really extract things if they're identical in 3+ places, or quite similar in 5+ places. Also, DI very good if you know what you're doing. Especially with typescript or other fake-strict languages, you don't actually need an interface and a class, you just say storage: { store: (item: something)=>Promise} and provide an object that has a store method taking something returning a promise, and what happens from there is irrelevant. You probably will have classes or at least some helpers for S3 storage and FTP storage, but you don't need a MockStorage class for testing, you just inline that shit. Have some weird edge case? Inline that shit. It's quite pleasant to work with if you don't have to explicitly state every behavior and can just wing it (again, for dev/testing only, wouldn't recommend in production, but then again it probably won't break, just not as easy to maintain). And you can mock write a Harder Drive implementation.

"What's WebDAV" made my cry so hard because I didn't know it either until I had to re-do a whole "FileTransfer" Lib in our Common Lib where I had to reimplement all the connectivity of the possible endpoints for filetransfer, including FTB, SFTP and "ofc" WebDAV. WebDAV nearly made me cry, maybe it was our infra or WebDAV is just coming literally out of hell, idk haha.

I see some value in DI/mock/tests in that you can ask the simple question "if y is working, why is caller x (or forward call z) blowing up? If it's not working, how does x (or z) handle it?". That simple yes/no will suffice for most things. It can even help with transient conditions if (at the boundaries) your parameters are reduced to a "generic" message passing object that both carries back the reply, if any, AND the state of the "operation". Your caller must now decide if when presented with "failed because of K" it wants to just fail, or handle the fail and retry, or....,etc. For me though, the true value is that it burns into you the idea of "interfaces at boundaries". Going forward, even when you're not using any of it, you start to instinctively "feel" when you crossed the line between (what should be) a and b components. Eventually you start NOT doing "monolithic" and also stay away from "abstraction i don't need". Hopefully... p.s. loved the SQLite mention. Had to "hard sell it" to my colleagues the other day and boy, was it a tough battle... What brought it home was the logical conclusion that if you wrap all of it in a "container", you can actually commit the state to a file at any point AND restore from that checkpoint at any time. The value of that when testing for "elusive bugs" can not be understated. p.p.s I only use SQLite when things are stable enough. First port of call is a simple "memory mapped" container that can be checkpoint'ed to/from a json file. It mimics "ideal conditions" and let's you test the code "if all was working properly". If so, and when the overall architecture is "stabilized" you move to the SQLite implementation so it's easier to do postmortem analysis if needed. Best part is that, using any of these (and client allowing), we can pull the live data from the SQLServer/MySQL/etc at any time with a tool, save it to a file, transfer it and our support team can play around with it to see what is happening when under clients state in an environment with full debug capabilities. Can save you a LOT of time over having someone checking it at the client's front end while someone else is sifting through backend logs, dead and live.

The point is you need to balance between Reuse and Ease of use. Same as when someone says composition over inheritance. NOOOO. You need to understand when to use what. But 1 thing never fails, make it as simple as possible that doesn't jeopardize functionality and testability.

I think the unit testing at 24:49 helps guard against regression. You assert behavior this way, and if tomorrow some dev comes in and decides to refactor because he doesn't like the way it was written, you'll catch any functional braking changes introduced. I also had a hard time with this time of test initially and found them useless, but on large projects they are very useful. Granted, e2e tests can also cover this, but you have to write a lot more code to cover possible scenarios because of all the other branching that can occur.

Been waiting for this one! Love the take good stuff!!!!

27:50 that’s my problem. I learned SOLID and other design patterns and now I end up using dependency injection and abstraction and all that…. Before I even have more than 1 implementation for my interfaces. I try to design the app around abstraction instead of just coding and if something goes gross refactoring.

Patterns allow DRY. Overuse of patterns can overly abstract and overcomplicate a codebase.

All of the strategy pattern does is abide to SOLID, probably more so than other patterns. Just kinda feel Prime is arguing for and against the same point 😅 However if the his take is that you don't need to know SOLID but use patterns, then sure, I agree. I never use Liskov's Substitution. Because I refuse to take L's.

For any c++ person, to whom all these buzz words sound like childish giberish, this is basically using interfaces and inheritence where you pass the object pointer under the interface type. (And you allow others to also implement that interface any way they see fit)

Prime is the only tech-youtuber whose wife serves him plate of food during recordings. Not because she loves him, but because Prime, for some unexplained reason, being a programmer, also has a wife...

Fully agree with the take on testing at 24:14. What you want there is maybe an integration test but a noop pipe through test is pretty pointless unless you want to check your input validation. To many goofballs go mental about 100%, or close to, test coverage

I prefer the FOB (Fauci-Ouchi Booster) design pattern for all my bwazingly fwast needs ❤

"is mayonnaise a strategy?" "I think so" 😂

DI without a container is wild.

What you tried to do with Typescript might be `interface Foo { readonly a: number}; let foo: Foo = {a: 5}; foo = {a: 42};` Reassigning foo is fine, but the value itself is constant. `foo.a = 69`; is not valid. With a lint rule in eslint-functional , you can force all interfaces to be readonly like that and make ts an almost functional language.

If you use precondition checks, you can significantly narrow the possible error surface of your code, thus obviating the need for high levels of testing for errors -- you just have to document that supplying invalid arguments/inputs to your code will result in whatever errors your precondition checks return/raise. This also makes it really easy for users of your code to understand what they did wrong because you explicitly tell them what they did wrong.

What is great with these videos is that these are the things new coders don't get enough of. They learn crappy quick solutions for easy ass projects and have to learn through experience how why and when to use a strategy pattern, a factory pattern, when to repeat or not to repeat. I've seen way too many express server examples expanded to become gigantic projects. Great job on CodeAesthetic's part. However yeah the issue is devs finding these hammers and then seeing everything as a nail. And yes the tests aren't testing anything typescript is already testing, the trouble in these scenarios is always having the right testing environement for e2e, you need a testing s3, a testing db, possibly a testing environement with the correct network connections between services... you need to reset that shit after the tests... it quickly becomes tedious.