Hello once again! Today's lesson is centered around leveraging the principles of Object-Oriented Programming (OOP) — Encapsulation, Abstraction, Polymorphism, and Composition — to enhance code readability and structure. Buckle up for an exciting journey ahead!
OOP principles act as a scaffold for building readable, maintainable, and flexible code — these are the characteristics we seek while refactoring. By creating logical groupings of properties and behaviors in classes, we foster a codebase that's easier to comprehend and modify. Let's put this into perspective as we progress.
Encapsulation involves bundling related properties and methods within a class, thereby creating an organization that mirrors the real world.
Suppose we possess scattered student information within our program.
C#1string studentName = "Alice"; 2int studentAge = 20; 3double studentGrade = 3.9; 4 5public static void DisplayStudentInfo() 6{ 7 Console.WriteLine("Student Name: " + studentName); 8 Console.WriteLine("Student Age: " + studentAge); 9 Console.WriteLine("Student Grade: " + studentGrade); 10} 11 12public static void UpdateStudentGrade(double newGrade) 13{ 14 studentGrade = newGrade; 15}
Although functional, the code could cause potential confusion as the related attributes and behaviors aren't logically grouped. On top of that, all these fields are mutable and accessible from outer scope, introducing a bunch of security concerns. Let's encapsulate!
C#1public class Student 2{ 3 private string name; 4 private int age; 5 private double grade; 6 7 public Student(string name, int age, double grade) 8 { 9 this.name = name; 10 this.age = age; 11 this.grade = grade; 12 } 13 14 public void DisplayStudentInfo() 15 { 16 Console.WriteLine("Student Name: " + name); 17 Console.WriteLine("Student Age: " + age); 18 Console.WriteLine("Student Grade: " + grade); 19 } 20 21 public void UpdateStudentGrade(double newGrade) 22 { 23 this.grade = newGrade; 24 } 25 26 // Properties for encapsulated fields 27 public string Name 28 { 29 get { return name; } 30 set { name = value; } 31 } 32 33 public int Age 34 { 35 get { return age; } 36 set { age = value; } 37 } 38 39 public double Grade 40 { 41 get { return grade; } 42 set { grade = value; } 43 } 44}
After refactoring, all student-related properties and methods are contained within the Student
class, thereby enhancing readability and maintainability.
Next up is Abstraction. It is about exposing the relevant features and concealing the complexities.
Consider a code snippet calculating a student's grade point average (GPA
) through complex operations:
C#1public static double CalculateGpa(string[] grades) 2{ 3 int totalPoints = 0; 4 var gradePoints = new Dictionary<string, int> 5 { 6 {"A", 4}, {"B", 3}, {"C", 2}, {"D", 1}, {"F", 0} 7 }; 8 foreach (var grade in grades) 9 { 10 totalPoints += gradePoints[grade]; 11 } 12 return (double)totalPoints / grades.Length; 13}
We can encapsulate this within the CalculateGpa()
method of our Student
class, thereby simplifying the interaction.
C#1public class Student 2{ 3 private string name; 4 private string[] grades; 5 private double gpa; 6 7 public Student(string name, string[] grades) 8 { 9 this.name = name; 10 this.grades = grades; 11 this.gpa = CalculateGpa(); 12 } 13 14 private double CalculateGpa() 15 { 16 int totalPoints = 0; 17 var gradePoints = new Dictionary<string, int> 18 { 19 {"A", 4}, {"B", 3}, {"C", 2}, {"D", 1}, {"F", 0} 20 }; 21 foreach (var grade in grades) 22 { 23 totalPoints += gradePoints[grade]; 24 } 25 return (double)totalPoints / grades.Length; 26 } 27 28 public string Name 29 { 30 get { return name; } 31 set { name = value; } 32 } 33 34 public string[] Grades 35 { 36 get { return grades; } 37 set 38 { 39 grades = value; 40 gpa = CalculateGpa(); 41 } 42 } 43 44 public double Gpa 45 { 46 get { return gpa; } 47 } 48}
We can now access the gpa
as an attribute of the student object, which is calculated behind the scenes.
Polymorphism provides a unified interface for different types of actions, making our code more flexible.
Assume we are developing a simple graphics editor. Here is a code snippet without Polymorphism:
C#1public class Rectangle 2{ 3 public void DrawRectangle() 4 { 5 Console.WriteLine("Drawing a rectangle."); 6 } 7} 8 9public class Triangle 10{ 11 public void DrawTriangle() 12 { 13 Console.WriteLine("Drawing a triangle."); 14 } 15}
We have different method names for each class. We can refactor this to have a singular Draw
method common to all shapes:
C#1public abstract class Shape 2{ 3 public abstract void Draw(); 4} 5 6public class Rectangle : Shape 7{ 8 public override void Draw() 9 { 10 Console.WriteLine("Drawing a rectangle."); 11 } 12} 13 14public class Triangle : Shape 15{ 16 public override void Draw() 17 { 18 Console.WriteLine("Drawing a triangle."); 19 } 20}
Now, regardless of the shape of the object, we can use Draw()
to trigger the appropriate drawing behavior, thus enhancing flexibility.
Our last destination is Composition, which models relationships between objects and classes. Composition allows us to design our systems in a flexible and maintainable way by constructing complex objects from simpler ones. This principle helps us manage relationships by ensuring that objects are composed of other objects, thus organizing dependencies more neatly and making individual parts easier to update or replace.
Consider a system in our application that deals with rendering various UI elements. Initially, we might have a Window
class that includes methods both for displaying the window and managing content like buttons and text fields directly within it.
C#1public class Window 2{ 3 private string content; 4 5 public Window() 6 { 7 this.content = "Default content"; 8 } 9 10 public void AddTextField(string content) 11 { 12 this.content = content; 13 } 14 15 public void Display() 16 { 17 Console.WriteLine("Window displays: " + content); 18 } 19}
This approach tightly couples the window display logic with the content management, making changes and maintenance harder as we add more elements and functionalities. Let's now see how we can update this code with composition.
To implement Composition, we decouple the responsibilities by creating separate classes for content management (ContentManager
) and then integrating these into our Window
class. This way, each class focuses on a single responsibility.
C#1public class ContentManager 2{ 3 private string content; 4 5 public ContentManager() 6 { 7 this.content = "Default content"; 8 } 9 10 public void UpdateContent(string newContent) 11 { 12 this.content = newContent; 13 } 14 15 public string GetContent() 16 { 17 return content; 18 } 19} 20 21public class Window 22{ 23 private ContentManager manager; 24 25 public Window() 26 { 27 this.manager = new ContentManager(); 28 } 29 30 public void Display() 31 { 32 Console.WriteLine("Window displays: " + manager.GetContent()); 33 } 34 35 public void ChangeContent(string newContent) 36 { 37 manager.UpdateContent(newContent); 38 } 39}
By refactoring with Composition, we've encapsulated the content management within its class. The Window
class now "has a" ContentManager
, focusing on displaying the window. This separation allows for easier modifications in how content is managed or displayed without altering the other's logic. Composition, in this way, enhances our system's flexibility and maintainability by fostering a cleaner and more modular design.
Great job! We've learned how to apply OOP principles to refactor code for improved readability, maintainability, and scalability.
Now, get ready for some exciting exercises. Nothing strengthens a concept better than practice! Happy refactoring!