In my eyes, an Adapter and a Shim would be the same. A Facade on the other hand serves a different purpose. If you expect your client code to need to be able to pull back the curtain, so to speak, and access the underlying library without using your object model, that would be a … Read more
Yes, you should probably start off with pattern matching instead of the visitor pattern. See this interview with Martin Odersky (my emphasis): So the right tool for the job really depends on which direction you want to extend. If you want to extend with new data, you pick the classical object-oriented approach with virtual methods. … Read more
If you look at the first example at that Go Concurrency Patterns blog post, you’ll notice that they’re “deriving” their contexts from the Background context. That, combined with the Context and WithContext methods on your Request object, gives you what you need. I just figured this out (and it wasn’t my first run at reading … Read more
I think there are no specific design guidelines for this. But some of the design principles do talk about method creation. DRY ( don’t repeat yourself) is a guiding principle when comes to method creation. You group similar logic in a single method so that you don’t duplicate them all over your code and thus … Read more
DI and Strategy work in the same way, but Strategy is used for more fine-grained and short-lived dependencies. When an object is configured with a “fixed” Strategy, for example when the object is constructed, the distinction between Strategy and DI blurs. But in a DI scenario it is more unusual that the dependencies of objects … Read more
Traits are similar to interfaces: Traits are Rust’s sole notion of interface. An interface is meant to document available methods, to have an interface with private methods makes no sense. Correspondingly, in Rust you can’t have different levels of visibility in one trait. If you can see the trait, you can always see all of … Read more
Use Cases focus on Users, Actions, and Processes. This is great from a business perspective, because everyone can see an abstracted view of what the system will provide. DDD focuses on creating software that solves problems. The ‘Who can solve this?‘ and the ‘What process will they follow?‘ come afterwards. DDD really gets to the … Read more
I wholeheartedly agree with the YAGNI principle, but you still want to plan for success. If an application needs a complete rewrite when it suddenly has more than ten users, then it’s YAGNI taken too far. Some things You Are Gonna Need. From my perspective, the two most important points: Don’t shoot yourself in the … Read more
As requested, here are a few analogies: The Earth The Universe The element oxygen (there are other elements, but only one oxygen. There are lots of oxygen molecules, but only one canonical oxygen element.) The concept of True The concept of False You could instantiate lots of True objects, but they will all refer to … Read more
Because every organization has different needs, you should adapt your design while designing and building a dynamic and flexible user management system. Role Based Access Control (RBAC) is a common approach. In this model, users are assigned roles, and the roles have corresponding permissions. As a result, instead of granting permissions directly to users, permissions … Read more