How to Refactor a Java E‑commerce Login Module for IP and Time Restrictions

The original system already had a login feature, but a new requirement demanded security controls limiting login IP addresses (internal vs. external) and permissible login times. Users should only be able to log in from specified IPs during allowed time windows.

Original Code Issues

The existing implementation suffered from several problems:

IP and time checks were performed using string matching and boolean logic that could be simplified.

Time handling (hh:MM) was duplicated across the codebase instead of being centralized in a utility class.

String splitting for comma‑separated lists appeared in multiple places, lacking a reusable helper.

Three distinct business rules (time range, internal IP, external IP) were tangled together in nested loops, making the code hard to read and modify.

SecureLogEvent objects were instantiated without passing essential business data.

Comments were scarce, reducing code readability.

Method names were vague and did not convey intent.

Magic numbers and strings were scattered throughout the code instead of being defined as constants.

Refactoring Process

The author followed a systematic approach:

Read the original code to identify duplication.

Extract time‑handling logic into a private helper method.

Write a small main test to verify the new time logic before replacing the old code.

Identify common string‑splitting patterns and create a reusable utility method.

Separate the "allowed login time" check from the IP checks, removing it from the nested loops.

Isolate internal and external IP checks into independent loops.

After clarifying the business rules, restructure the code hierarchy for better readability.

Enhance logging by including valuable business data, add comments, and replace magic values with constants.

Change the original boolean‑returning call to use the new utility method.

Move the rule‑evaluation logic out of CreditController into a dedicated utility class, reducing controller size and improving future extensibility.

Refactored Code Highlights

The refactored version introduces a clear public method that returns a boolean indicating whether the login attempt should be blocked. Key improvements include:

Constants defined at the top for magic values.

A single public method that first checks the allowed time via a private forbitVisitTimeRange method.

Separate isInside and isOutside methods (using a shared checkRange helper) to replace the previous double loop.

A private recordLog method that accepts a concatenated business‑data string, ensuring logs contain actionable information.

Additional screenshots illustrate the before‑and‑after code structure, constant definitions, and the new utility class layout.

Key Takeaways

Eliminate duplicate code by extracting common functionality into reusable methods or utility classes.

Prefer framework‑provided or well‑tested third‑party utilities over reinventing the wheel.

When multiple loops are present, consider whether each business rule can be handled independently.

Comprehensive comments dramatically improve maintainability.

Replace magic strings/numbers with clearly named constants.

Log only meaningful business data to aid future debugging and incident analysis.