Describe Singleton

content/technologeek/books/2024-02-25-head-first-design-patterns/index.md

@@ -31,6 +31,30 @@ Les patterns ci-dessous sont orientés sur la nécessité de découpler des comp
 
 ### Singleton
 
+Le _Singleton_ s'assure de n'avoir (tout au long de la vie d'un programme) **qu'une et une seule** instance d'une classe particulière, afin d'éviter ne soit globale et ne consomme plein de ressources pour rien.
+
+Un Singleton peut être modélisé en rendant le constructeur **privé**, et en rendant l'accès à ce constructeur **statique** :
+
+```java
+public class Singleton {
+    private static Singleton uniqueInstance;
+
+    private Singleton();
+
+    public static Singleton getInstance() {
+        if (uniqueInstance == null) {
+            uniqueInstance = new Singleton();
+        }
+        return uniqueInstance;
+    }
+}
+```
+
+Comme le constructeur est privé, il ne peut être instancié que par la classe elle-même.
+La méthode de classe est par contre publique et permet de retourner la référence vers la seule instance (si elle existe) ou de la créer (dans le cas contraire).
+
+> Pour le multithreading, il convient d'utiliser des [Mutex](https://learn.microsoft.com/en-us/dotnet/standard/threading/mutexes) - qui correspond au mot-clé `synchronized` en Java - afin de s'assurer que chaque thread ne puisse appeler ces méthodes que chacun à son tour.
+
 
 ## Behavioral
 
@@ -149,7 +173,6 @@ Les observateurs reçoivent ces données pour les afficher différemment (= _Dis
 Comme améliorations, des propriétés du sujet peuvent être rendues publiques, afin que les observateurs puissent "choisir" spécifiquement les informations qu'ils pourraient vouloir afficher.
 
 
-
 ### Strategy
 
 > Plutôt que d'implémenter une forme d'héritage dès qu'on en a l'occasion, l'idée est de différencier l'élément de son comportement.
@@ -185,6 +208,14 @@ Attention qu'en termes de performances, ce pattern doit généralement être cou
 
 ### Decorator
 
+Le décorateur va fonctionner avec un mécanisme de délégations : chaque décoration pouvant être complétée par de nouvelles données provenant d'un nouveau décorateur.
+
+Le décorateur ajoute donc son propre comportement avant / après avoir délégué au comportement de l'objet qu'il décore.
+
+![](decorator.png)
+
+Un des (gros) désavantages de ce pattern se situe au niveau du nombre de (petites) classes qu'il va nécessiter de créer, ce qui peut être déconcertant.
+
 
 ### Adapter
 

drafts/2024-02-03-the-manager-path/index.md

@@ -1,117 +0,0 @@
----
-title: The Manager's Path
-description: A Guide for Tech Leaders Navigating Growth and Change
-writers: [Camille Fournier]
----
-
-The three types of managers to avoid :
-
-* Neglegt : he/she does not meet expectations, never gives feedback and avoid meetings.
-* Micromanaging : questions every details and refuses to let you make decisions.
-* Abusive : ignores you until they want to yell at you.
-
-The following includes my own notes about what I want to remember and the role that I'm interested in.
-
-== Essential features of a good relationship
-
-1. **Recurrent 1-2-1 meetings**, scheduled (or at least with some predictability). Meetings should come from both sides, with an agenda. These meetings create a extra human connection[^1] and create opportunity to speak privately about whatever needs being discussed. To prepare them, thinkg about topics to be discussed - for boring subjects, emails are just as good.
-2. **Feedback** : at one time or another, you will screw something. A quick feedback is essential, otherwise it will be uncomfortable. **The only thing worse than getting a behavioral feedback is not getting one at all, or getting it several months later**.
-3. **Finding trainings or conferences**, providing resources for career growth, getting you a promotion or advocating to get one.
-
-== How to be managed
-
-> Whether you are brand new or have 20 yeards into your career, the charge of figuring out what you want to do, what you want to learn and what makes you happy rest on _your_ shoulders.
-
-* **You are responsible for yourself** : ask for projects you want to work on. Advocate for yourself.
-* **Seek for feedback** : take it graciously when it comes to you.
-* **Give your managers a break** : it's only a job to do the best for the company and the team. He/she is not a psychologist. The only person you can change is yourself.
-
-== Mentoring
-
-Mentoring is the first step on the ladder to being a manager.
-It gives you the opportunity to learn in a fairly safe way about management and being responsible for another person.
-Mentoring can be about internships or new hires.
-
-=== Internships
-
-When dealing with internships, sit with the person as much as possible on the first day, and try to listen, communicate and adjust responses as much as possible :
-
-* **Listening is the most basic skill for managing**, and the precursor to empathy. People are not good at saying _precisely_ what they mean in a way that others can understand. You will need to translate questions and (really) pay attention to body language.
-* Be careful, as the intern might not ask question, though he/she should.
-* **Communicate clearly** what needs to happen, if he/she should do researches on its/her own before asking questions, explaining pieces of code, point to documents, ... All of these will learn something about its/her potential. Give him/her milestones and break projects into smaller parts.
-* **Calibrate responses and frequencies of interviews**.
-
-As a summary :
-
-* Prepare for his arrival,
-* Have a project for him to work on,
-* Plan to have him present his work at the end of the program.
-
-### New hires
-
-New hires are a bit different from interns, as they should have a little more experience.
-To prepare his start :
-
-1. Plan to have pair-programming, to learn the code base,
-2. Point to a glossary, because they are many bits of process, culture and second nature jargon - that you might not realize, but these are completely foreign for a newcomer.
-
-Good team have good onboarding documents they provide to newcomers : step-by-step guides, how to set up a ne dev environment, how to familizarize with tools, ...
-These documents should constantly evolve : **make new hires to complete these kinds of documents as their first task**.
-
-## Tech Lead
-
-## Bootstrapping a culture
-
-> Culture is how things get done, without people having to think about it.
->
-> -- Frédéric Laloux - Reinventing Organizations
-
-### Structure and processes
-
-Structure and processes are seen as pointless, see harmful.
-But :
-
-* Without any process, your team will struggle to scale.
-* With the wrong process, they will be slown down.
-
-In politics, a "good political idea" is one that works well in half-baked form.
-It should be the same in engineering : processes should have value even when they are not followed properly.
-
-Processes are necessary.
-To avoid scaring people, you should rather speak about :
-
-* Learning (instead of structure),
-* Transparency and sharing (rather than processes).
-
-### What matters
-
-You should see what's important for your colleagues, how they do manage uncertainty and risks, which kind of solutions they would choose by default (the perfect one, the ideal one or one "that works" ?).
-
-### Standards
-
-#### Code
-
-The code review (process) is a fail-safe for something we might have forgotten, that acts as transparency about applied changes, but it's also a socialization process.
-
-The only problem is that this process takes time, and everyone should not be onboarded right at the beginning.
-
-For the general layout, a simple Linter can be used (pylint, prettier, )
-
-> Linters aren't in your way. They're on your side.
->
-> -- https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/
-
-#### Post-mortem
-
-
-#### Architecture review
-
-
-#### Risks
-
-WHat kinds of risks concern our team ? Our institution ?
-How could we mitigate those risks without adding a lot of new totally useless processes or adding unwanted bureaucraty.
-
-## Conclusions
-
-Stay curious !