C# WinForms Refactoring — A Deeper Look with Tim Corey

What Refactoring Means in This Lesson

At 0:02, Tim introduces Lesson 24 and explains that refactoring means reworking code so it performs the same job, but in a better way. He points out that the application already works, but it contains “junk” and areas that are not up to standard. According to Tim, this is the right time to clean things up before the project grows further.

He emphasizes that refactoring is not about adding features—it’s about improving structure, readability, and long-term maintainability while keeping behavior the same.

Cleaning Up Unnecessary Return Values in Interfaces

Starting at 0:31, Tim dives into the first refactor: fixing interface method signatures. He explains that early in the project, methods were returning models unnecessarily. Since objects are already passed by reference, returning the same model again serves no real purpose.

Tim demonstrates changing these methods to void, which immediately breaks the implementations. He explains why this happens: when an interface changes, all implementing classes must match the new signature exactly. He walks through fixing the SQL connector and text connector to align with the updated interface.

At 2:33, Tim pauses to show what happens if you let Visual Studio auto-implement the interface. He explains why duplicate method names occur and clarifies that return types alone are not enough to differentiate method signatures.

Fixing Build Errors Caused by Refactoring

At 4:00, Tim builds the solution and intentionally shows the errors that appear. He explains that these errors are expected and helpful. For example, code that previously expected a returned model now fails because the method returns void.

Tim fixes this by removing unnecessary assignments and rebuilding the solution. He highlights that refactoring often causes short-term breakage, but each error points directly to code that needs improvement.

Moving File Name Constants to GlobalConfig

Beginning at 5:25, Tim refactors how file names are handled in the text connector. Previously, file paths were stored as private string constants inside the class. Tim explains that these are no longer needed because file names already exist in GlobalConfig.

He replaces local constants with GlobalConfig.PeopleFile, GlobalConfig.PrizesFile, and similar properties. Tim explains that this change centralizes configuration and ensures the entire application uses consistent file paths.

He also makes an important point: avoid refactoring too many things at once. When he notices additional improvements that could be made, he explicitly says he’ll come back to them later.

Refactoring the Text Connector Processor

At 7:44, Tim continues refactoring by removing file name parameters from multiple methods in the text connector processor. Since file names now live in GlobalConfig, passing them around is redundant.

Tim carefully updates method signatures, replaces parameters with GlobalConfig references, and relies on Visual Studio’s error list to guide him. He explains that seeing many errors at once is normal during refactoring and not something to panic about.

At 13:16, he notes how helpful real-time error tracking is when systematically cleaning up method calls across the project.

Identifying UI Logic That’s Doing Too Much

At 15:24, Tim highlights a major design issue: too much logic inside a UI event handler. He scrolls through a button click event and explains that it contains far more code than an event should. In Windows Forms, user actions such as button clicks are handled by event handlers, which define the specific action to be executed when the event occurs.

Tim explains that UI code should focus on user interaction only. Windows Forms uses an event-driven programming model, where user actions trigger events that are handled by application code. Business logic—such as scoring tournaments and advancing winners—belongs in a class library. This separation allows the same logic to be reused later in a web app or WPF application.

Extracting Tournament Logic into the Class Library

Starting at 17:55, Tim moves tournament scoring logic into a new public method inside the tournament logic class. He names it UpdateTournamentResults and explains why it accepts the entire tournament model, not just a single matchup.

He copies the logic out of the form, pastes it into the class library, and adjusts it to work independently of UI elements. This refactor ensures that tournament rules live in one place and can be reused anywhere.

Scoring Matchups and Handling Byes Correctly

At 21:37, Tim refactors how matchups are scored. Instead of working with a single matchup, he loops through all rounds and all matchups, building a list of matchups that need scoring.

He explains the logic for detecting completed games and bye weeks. Tim points out that bye weeks were previously handled in a “hacky” way by assigning fake scores. Refactoring allows him to handle byes explicitly and cleanly.

Extracting Scoring into Private Methods

At 28:17, Tim extracts scoring logic into a private method. He explains that smaller, focused methods make code easier to understand and maintain.

He also renames methods to better reflect what they do, such as changing scoring logic into something that clearly “marks winners in matchups.”

Configurable Winner Determination

Beginning at 29:58, Tim refactors winner determination logic so it can handle both high-score-wins and low-score-wins scenarios. He introduces a new application setting and explains why configuration is better than hard-coding rules.

Tim discusses alternative designs, including storing this value in the tournament model, but explains why that change is outside the scope of this lesson.

Advancing Winners and Saving Results

At 45:40, Tim moves on to advancing winners to the next round. He explains how winners are matched to parent matchups and why saving data at the correct time is critical.

Later, around 52:10, he demonstrates a concise ForEach approach to updating matchups, explaining how it’s functionally equivalent to a traditional loop but more compact.

Fixing Bugs Introduced by Refactoring

At 58:33, Tim discovers incorrect data in the database and traces the issue back to calling logic before the tournament was saved. He explains how refactoring sometimes exposes hidden bugs rather than creating new ones.

By moving the update logic to the correct location—after persistence—Tim resolves the issue and retests the application.

Final Thoughts on Refactoring

At 1:09:00, Tim wraps up by summarizing what refactoring achieved in this lesson. He explains that refactoring is not just about cleaner code—it’s also about handling edge cases, fixing design flaws, and preparing for future changes.

He emphasizes that refactoring is an ongoing process and hints that the next lesson will focus on error handling.