The next day, I was walking down the corridor when I heard Infinity's voice coming from the conference room. She sounded very stressed, which was far from her typical confident demeanor. The talk must be significant, I thought, and before I could stop myself, I began to eavesdrop.
"What do you mean, faster? I have all of my resources working on Rust;
there's nothing left to add!" Infinity shouted.
"It's too slow. You haven't made any attacks during the last month," the
male voice answered.
"My sister was kidnapped; she barely survived," Infinity shot back. "We
couldn't just leave her there to be interrogated."
"You're putting your own interest higher than our mission. Your sister is
just a programmer, we lose more and more every day," the voice said.
There was a pause. A long one. Even though I wasn't participating in the discussion, I could feel the tremendous tension in the air. Finally, Infinity got her voice back. "You are right, Commander. It won't happen again. Our mission is more important than my sister's life."
It was clear that this was what the commander was looking for Inifinity to say. But how does someone will themselves to say something so coarse and lifeless? It's easy to hear such phrases in movies, where the actors are playing roles, but to hear it in the context of an actual human life... Infinity giving her word that the next time there was a choice between completing a mission and saving her sister's life, she would choose the former. Scary. Is this why she was chosen as the leader of the resistance in Wonderland? Was it out of weakness or strength that she could decided to put the mission before her family? Who was the commander asking her to give up so much? Noname would probably know. With his deep access in the network, he probably had access to personnel files.
"Noname, who is in the conference room now?" I asked silently.
"Hi Teo, just one person, Infinity," Noname replied.
"She was talking to someone. Please check again," I said.
"In the modern world, Teo, there are ways to talk to people even if they're
not in the same room! My records are spotty that far back, but I'm pretty
sure it was possible in your time, 2018, as well. Maybe called a conference
call? Such simple technology!"
"Noname, who was she talking to?" I began to miss the straight-to-the-point
British personality Noname used to have.
"The channel was encrypted. I don't have any way to retrieve the credentials
of whoever was talking to Infinity, sorry."
"That's fine, don't worry, friend," I replied.
Who was this Commander?
In class the next day, we learned a new topic - encapsulation. Sintia was
wearing jeans and a t-shirt, casual as usual.
"Have you ever heard the term 'encapsulation'? No? This is one of the
fundamental concepts in object-oriented programming.
Encapsulation
has two goals:"
"Sintia..." two students said over one another.
"I know, I know. Far too abstract. I'll explain by example. Take a look at
this code snippet:"
class Car
{
public void PrintPrice(decimal price)
{
Console.WriteLine($"Car costs {price}");
}
public void PrintDiscountPrice(decimal price, int discount)
{
Console.WriteLine($"Price with discount is {price - discount}");
}
}
class CarSetup
{
public static void Main()
{
var carPrice = decimal.Parse(Console.ReadLine());
var carDiscount = int.Parse(Console.ReadLine());
var car = new Car();
car.PrintPrice(carPrice);
car.PrintDiscountPrice(carPrice, carDiscount);
}
}
"Does anything about this code jump out at you?" Sintia asked.
"Is anyone else using variables
carPrice
and
carDiscount
?" I asked.
"No, they are used only to call methods on an object of type
Car
."
"Then I don't see any sense in keeping
carPrice
and
carDiscount
outside of the class
Car
," I said.
"Good, Teo. So how would you rewrite this code snippet? Here, I'll show the
result to the class," Sintia said, swiping on her tablet to show my work on
the wall.
I rewrote the code as follows:
class Car
{
public decimal Price;
public int Discount;
public void PrintPrice()
{
Console.WriteLine($"Car costs {Price}");
}
public void PrintDiscountPrice()
{
Console.WriteLine($"Price with discount is {Price - Discount}");
}
}
class CarSetup
{
public static void Main()
{
var carPrice = decimal.Parse(Console.ReadLine());
var carDiscount = int.Parse(Console.ReadLine());
var car = new Car
{
Price = carPrice,
Discount = carDiscount
};
car.PrintPrice();
car.PrintDiscountPrice();
}
}
"Exactly how I would do it!" Sintia declared, sounding genuinely impressed.
"This code is a good representation of
the first encapsulation concept: to keep data and methods that work with
that data in one class.
Class
Car
contains data fields
Discount
and
Price
, as well as the methods that work with those,
PrintPrice
and
PrintDiscount
," Sintia said.
"I can improve this code snipped even further!" said one of the students in
the room.
"Go ahead!" Sintia projected the results of his work to the wall:
class Car
{
public decimal Price { get; }
public int Discount { get; }
public Car(decimal price, int discount)
{
Price = price;
Discount = discount;
}
public void PrintPrice()
{
Console.WriteLine($"Car costs {Price}");
}
public void PrintDiscountPrice()
{
Console.WriteLine($"Price with discount is {Price - Discount}");
}
}
class SomeOtherClass
{
public static void Main()
{
var carPrice = decimal.Parse(Console.ReadLine());
var carDiscount = int.Parse(Console.ReadLine());
var car = new Car(carPrice, carDiscount);
car.PrintPrice();
car.PrintDiscountPrice();
}
}
"Okay, and can you explain why this is an improvement?" Sintia asked the
student.
"Because this code corresponds to the second encapsulation concept:
it restricts a direct access to all fields and sets the value through the
constructor.
"
"Well done! In general, Public fields are usually not welcome in C#. Public fields expose the inner state of your class, allowing anyone to change it, " Sintia summed up, adding, " The handout you picked up at the beginning of class lists more advantages of using encapsulation. Read it over, take a quick break, and we'll start coding in ten minutes."
"It feels like we're advancing into software architecture principles and
best practices!" I told Sintia during the break.
"Exactly, Teo. To be a good programmer, you need to know more than just the
syntax of a programming language. You have to have the right mindset."
"Okay everyone, take your seats," Sintia said. "Here are the tasks I want you to work through."