From 1e1fb7dc22816d368a17b5944a812d94de8600db Mon Sep 17 00:00:00 2001 From: Jack Hodges Date: Sun, 8 Oct 2023 17:16:33 +1100 Subject: [PATCH 1/3] Added documentation for Feature Toggle design pattern --- feature-toggle/README.md | 63 +++++++++++++++++++++++++++++++++++++--- 1 file changed, 59 insertions(+), 4 deletions(-) diff --git a/feature-toggle/README.md b/feature-toggle/README.md index 915a255690da..ec78bab8edaa 100644 --- a/feature-toggle/README.md +++ b/feature-toggle/README.md @@ -10,10 +10,53 @@ tag: Feature Flag ## Intent -Used to switch code execution paths based on properties or groupings. Allowing new features to be released, tested -and rolled out. Allowing switching back to the older feature quickly if needed. It should be noted that this pattern, -can easily introduce code complexity. There is also cause for concern that the old feature that the toggle is eventually -going to phase out is never removed, causing redundant code smells and increased maintainability. +A technique used in software development to control and manage the rollout of specific features or functionality in a +program without changing the code. It can act as an on/off switch for features depending on the status or properties of +other values in the program. This is similar to A/B testing, where features are rolled out based on properties such as +location or device. Implementing this design pattern can increase code complexity, and it is important to remember to +remove redundant code if this design pattern is being used to phase out a system or feature. + +## Explanation +Real-world Example +> This design pattern works really well in any sort of development, in particular mobile development. Say you want to +> introduce a feature such as dark mode, but you want to ensure that the feature works correctly and don't want to roll +> out the feature to everyone immediately. You write in the code, and have it switched off as default. From here, it is +> easy to turn on the code for specific users based on selection criteria, or randomly. This will also allow the feature +> to be turned off easily without any drastic changes to the code, or any need for redeployment or updates. + +In plain words +> Feature Toggle is a way to introduce new features gradually instead of deployment all at once. + +Wikipedia says +> A feature toggle in software development provides an alternative to maintaining multiple feature branches in source +> code. A condition within the code enables or disables a feature during runtime. In agile settings the toggle is +> used in production, to switch on the feature on demand, for some or all the users. + +## Programmatic Example +This example shows Java code that allows a feature to show when it is enabled by the developer, and when a user is a +Premium member of the application. This is useful for subscription locked features. +```java +public class FeatureToggleExample { + // Bool for feature enabled or disabled + private static boolean isNewFeatureEnabled = false; + + public static void main(String[] args) { + boolean userIsPremium = true; // Example: Check if the user is a premium user + + // Check if the new feature should be enabled for the user + if (userIsPremium && isNewFeatureEnabled) { + // User is premium and the new feature is enabled + showNewFeature(); + } + } + + private static void showNewFeature() { + // If user is allowed to see locked feature, this is where the code would go + } +} +``` +The code shows how simple it is to implement this design pattern, and the criteria can be further refined or broadened +should the developers choose to do so. ## Class diagram ![alt text](./etc/feature-toggle.png "Feature Toggle") @@ -24,7 +67,19 @@ Use the Feature Toggle pattern when * Giving different features to different users. * Rolling out a new feature incrementally. * Switching between development and production environments. +* Quickly disable problematic features +* External management of feature deployment +* Ability to maintain multiple version releases of a feature +* 'Hidden' deployment, releasing a feature in code for designated testing but not publicly making it available + +## Consequences +Consequences involved with using the Feature Toggle pattern + +* Code complexity is increased +* Testing of multiple states is harder and more time-consuming +* Confusion between friends on why features are missing ## Credits * [Martin Fowler 29 October 2010 (2010-10-29).](http://martinfowler.com/bliki/FeatureToggle.html) +* [Feature Toggle - Java Design Patterns](https://java-design-patterns.com/patterns/feature-toggle/) From 1b2a8d8704cdd87fcf16f05935353367fec32624 Mon Sep 17 00:00:00 2001 From: Jack Hodges Date: Sun, 8 Oct 2023 17:20:10 +1100 Subject: [PATCH 2/3] Explanation for Feature Toggle Issue #2230 finished, added intent, explanation, programmatic example, applicability and consequences --- feature-toggle/README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/feature-toggle/README.md b/feature-toggle/README.md index ec78bab8edaa..982108bc7440 100644 --- a/feature-toggle/README.md +++ b/feature-toggle/README.md @@ -78,6 +78,7 @@ Consequences involved with using the Feature Toggle pattern * Code complexity is increased * Testing of multiple states is harder and more time-consuming * Confusion between friends on why features are missing +* Keeping documentation up to date with all features can be difficult ## Credits From 2d4b2eac63340b434d8f89a78384eb8108552fac Mon Sep 17 00:00:00 2001 From: jackhodges Date: Wed, 25 Oct 2023 16:13:45 +1100 Subject: [PATCH 3/3] Finished Explanation for Leader/Followers #2239 --- leader-followers/README.md | 93 ++++++++++++++++++++++++++++++++++---- 1 file changed, 84 insertions(+), 9 deletions(-) diff --git a/leader-followers/README.md b/leader-followers/README.md index 6c24e33bf570..5198097883c1 100644 --- a/leader-followers/README.md +++ b/leader-followers/README.md @@ -3,28 +3,103 @@ title: Leader/Followers category: Concurrency language: en tag: - - Performance +- Performance --- ## Intent -The Leader/Followers pattern provides a concurrency model where multiple -threads can efficiently de-multiplex events and dispatch event handlers -that process I/O handles shared by the threads. +The Leader/Followers design pattern is a pattern used to coordinate a selection of 'workers'. It allows tasks to execute concurrently +with the Leader delegating tasks to the Follower threads for execution. It is a very common design pattern used in multithreaded +situations such as servers, and works to help prevent ambiguity around delegation of tasks. +## Explanation +Real-world Example +> The best real world example of Leader/Followers is a web server. Web servers have to be able to handle a multitude of incoming +> connections all at once. In a web server, the Leader/Followers pattern works by using the Leader to listen to incoming requests +> and accept connections. Once a connection is made to a client the Leader can then find a Follower thread to delegate the task +> to for execution and return to the client. This means that the Leader does not have to wait to finish execution before it can +> accept another incoming connection, and can focus on delegating tasks. This pattern is created to aid in concurrency of applicaitons, +> allowing for many connections to work simultaneously. + +In plain words +> You can picture the Leader as a traffic controller that has to direct traffic from one lane into 25 lanes. As a car comes in, +> the Leader sends it down a road that isn't full or busy. This car can then have its request filled, or reach its destination. +> If the Leader had to drive each car down the lane itself, the line would pile up and progress would be slow. But as the Leader +> has Followers that can also drive the cars, the Leader can focus on making the line move quickly and ensuring traffic doesn't +> back up. + +Wikipedia says +> A concurrency pattern are those types of design patterns that deal with the multi-threaded programming paradigm. + +## Programmatic Example +This example shows Java code that sets up a Leader that listens for client requests on port 8080. Once a request is sent, +the leader will accept it and delegate it to a new Follower to execute. This means that the Leader can keep delegating, +and ensure requests are fulfilled timely. This is only pseudocode and the working code would require a more concrete implementation +of Leader and Followers. +```java +public class LeaderFollowerWebServer { + + public static void main(String[] args) throws IOException { + int port = 8080; // the port that clients can reach the leader on + int numFollowers = 5; // the amount of followers we can delegate tasks to + + ServerSocket serverSocket = new ServerSocket(port); // pseudocode for creating a socket to the server + ExecutorService executorService = Executors.newFixedThreadPool(numFollowers); // pseudocode to start execution for Followers + + System.out.println("Web server started. Listening on port " + port); + + while (true) { + Socket clientSocket = serverSocket.accept(); + // Accept a new connection and assign it to a follower thread for processing + executorService.execute(new Follower(clientSocket)); + } + } +} + +class Follower implements Runnable { + private final Socket clientSocket; + + public Follower(Socket clientSocket) { + this.clientSocket = clientSocket; + } + + @Override + public void run() { + try { + // handle the client request, e.g., read and write data + // this is where you would implement your request processing logic. + // we will just close the socket + clientSocket.close(); + } catch (IOException e) { + e.printStackTrace(); + } + } +} +``` ## Class diagram ![Leader/Followers class diagram](./etc/leader-followers.png) ## Applicability Use Leader-Followers pattern when -* multiple threads take turns sharing a set of event sources in order to detect, de-multiplex, dispatch and process service requests that occur on the event sources. +* You want to establish a concurrent application +* You want faster response times on heavy load +* You want an easily scalable program +* You want to load balance a program + +## Consequences +Consequences involved with using the Leader/Followers pattern + +* Implementing this pattern will increase complexity of the code +* If the leader is too slow at delegating processes, some Followers may not get to execute tasks leading to a waste of resources +* There is overhead with organising and maintaining a thread pool +* Debugging is more complex ## Real world examples -* [ACE Thread Pool Reactor framework](https://www.dre.vanderbilt.edu/~schmidt/PDF/HPL.pdf) -* [JAWS](http://www.dre.vanderbilt.edu/~schmidt/PDF/PDCP.pdf) -* [Real-time CORBA](http://www.dre.vanderbilt.edu/~schmidt/PDF/RTS.pdf) +* ACE Thread Pool Reactor framework +* JAWS +* Real-time CORBA ## Credits -* [Douglas C. Schmidt and Carlos O’Ryan - Leader/Followers](http://www.kircher-schwanninger.de/michael/publications/lf.pdf) +* Douglas C. Schmidt and Carlos O’Ryan - Leader/Followers \ No newline at end of file