tiennm99/java-design-patterns
1
0
Fork 0
mirror of https://github.com/tiennm99/java-design-patterns.git synced 2026-05-15 06:58:41 +00:00
Code Issues Packages Projects Releases Wiki Activity

Resolves checkstyle errors for feature-toggle fluentinterface flux flyweight front-controller (#1078)

Browse Source 
* Reduces checkstyle errors in feature-toggle

* Reduces checkstyle errors in fluentinterface

* Reduces checkstyle errors in flux

* Reduces checkstyle errors in flyweight

* Reduces checkstyle errors in front-controller
This commit is contained in:
Anurag Agarwal
2019-11-12 01:54:23 +05:30
committed by Ilkka Seppälä
parent c954a436ad
commit 37599eb48f
46 changed files with 197 additions and 258 deletions
Download Patch File Download Diff File Expand all files Collapse all files
feature-toggle/src/main/java/com/iluwatar/featuretoggle/App.java
+28 -26
View File
@@ -28,46 +28,47 @@ import com.iluwatar.featuretoggle.pattern.propertiesversion.PropertiesFeatureTog
import com.iluwatar.featuretoggle.pattern.tieredversion.TieredFeatureToggleVersion;
import com.iluwatar.featuretoggle.user.User;
import com.iluwatar.featuretoggle.user.UserGroup;
import java.util.Properties;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.util.Properties;
/**
* The Feature Toggle pattern allows for complete code executions to be turned on or off with ease. This allows features
* to be controlled by either dynamic methods just as {@link User} information or by {@link Properties}. In the App
* below there are two examples. Firstly the {@link Properties} version of the feature toggle, where the enhanced
* version of the welcome message which is personalised is turned either on or off at instance creation. This method
* is not as dynamic as the {@link User} driven version where the feature of the personalised welcome message is
* The Feature Toggle pattern allows for complete code executions to be turned on or off with ease.
* This allows features to be controlled by either dynamic methods just as {@link User} information
* or by {@link Properties}. In the App below there are two examples. Firstly the {@link Properties}
* version of the feature toggle, where the enhanced version of the welcome message which is
* personalised is turned either on or off at instance creation. This method is not as dynamic as
* the {@link User} driven version where the feature of the personalised welcome message is
* dependant on the {@link UserGroup} the {@link User} is in. So if the user is a memeber of the
* {@link UserGroup#isPaid(User)} then they get an ehanced version of the welcome message.
*
* Note that this pattern can easily introduce code complexity, and if not kept in check can result in redundant
* unmaintained code within the codebase.
*
* <p>Note that this pattern can easily introduce code complexity, and if not kept in check can
* result in redundant unmaintained code within the codebase.
*/
public class App {
private static final Logger LOGGER = LoggerFactory.getLogger(App.class);
/**
* Block 1 shows the {@link PropertiesFeatureToggleVersion} being run with {@link Properties} setting the feature
* toggle to enabled.
* Block 1 shows the {@link PropertiesFeatureToggleVersion} being run with {@link Properties}
* setting the feature toggle to enabled.
*
* Block 2 shows the {@link PropertiesFeatureToggleVersion} being run with {@link Properties} setting the feature
* toggle to disabled. Notice the difference with the printed welcome message the username is not included.
* <p>Block 2 shows the {@link PropertiesFeatureToggleVersion} being run with {@link Properties}
* setting the feature toggle to disabled. Notice the difference with the printed welcome message
* the username is not included.
*
* Block 3 shows the {@link com.iluwatar.featuretoggle.pattern.tieredversion.TieredFeatureToggleVersion} being
* set up with two users on who is on the free level, while the other is on the paid level. When the
* {@link Service#getWelcomeMessage(User)} is called with the paid {@link User} note that the welcome message
* contains their username, while the same service call with the free tier user is more generic. No username is
* printed.
* <p>Block 3 shows the {@link
* com.iluwatar.featuretoggle.pattern.tieredversion.TieredFeatureToggleVersion} being set up with
* two users on who is on the free level, while the other is on the paid level. When the {@link
* Service#getWelcomeMessage(User)} is called with the paid {@link User} note that the welcome
* message contains their username, while the same service call with the free tier user is more
* generic. No username is printed.
*
* @see User
* @see UserGroup
* @see Service
* @see PropertiesFeatureToggleVersion
* @see com.iluwatar.featuretoggle.pattern.tieredversion.TieredFeatureToggleVersion
* @see User
* @see UserGroup
* @see Service
* @see PropertiesFeatureToggleVersion
* @see com.iluwatar.featuretoggle.pattern.tieredversion.TieredFeatureToggleVersion
*/
public static void main(String[] args) {
@@ -82,11 +83,12 @@ public class App {
final Properties turnedOff = new Properties();
turnedOff.put("enhancedWelcome", false);
Service turnedOffService = new PropertiesFeatureToggleVersion(turnedOff);
final String welcomeMessageturnedOff = turnedOffService.getWelcomeMessage(new User("Jamie No Code"));
final String welcomeMessageturnedOff =
turnedOffService.getWelcomeMessage(new User("Jamie No Code"));
LOGGER.info(welcomeMessageturnedOff);
// --------------------------------------------
Service service2 = new TieredFeatureToggleVersion();
final User paidUser = new User("Jamie Coder");