The document discusses strategies for working with legacy C++ code, including gaining control over legacy code through iterative refactoring while ensuring existing functionality is maintained. It emphasizes learning what the code does, making sure it continues functioning properly, and making gradual improvements. Specific techniques mentioned include writing tests, creating fake objects to inject into code under test instead of real dependencies, and using templates or friendship to fake classes that are otherwise difficult to mock.

1. Working with
C++ Legacy Code
Dror Helper | www.helpercode.com | @dhelper

2. Consultant @CodeValue
Developing software since 2002
Clean Coder & Test Driven Developer
Pluralsight author
https://www.pluralsight.com/authors/dror-helper
B: http://helpercode.com
T: @dhelper
About.ME

3. ¯_(ツ)_/¯
What is “Legacy Code”?
Covfefe?

4. No longer engineered – continuedly patched

5. Difficult to change without breaking functionality

6. Written by someone else

7. Legacy code has users!

8. The good news and bad news
There’s a lot of legacy C++ Code
There’s a good chance you’re doing it
C++ makes it easy to make critical mistakes
C++ is a powerful language

9. Gaining control over legacy code
To stop fearing legacy code:
1. Learn what the code does
2. Make sure it keeps doing it!
3. Iterative improvement via Refactoring

10. This is a unit test (GTest)
TEST(HolyGrailTests, WhoWeAreTest)
{
Knight knight;
ASSERT_EQ(“Ni!”, knight.Say());
}

11. A quick reality check
• Code have dependencies
• Refactoring == code change
• Code change == breaking functionality (78.3%)
• Breaking functionality  go home == false

12. Sensing and Separation
public void SendEmailTest()
{
auto sut = new ...
User user;
sut->SendEmailToUser(user);
// Sensing problem
ASSERT???
}
void SendEmailToUser(User user)
{
EmailClient client;
// Separation problem
client.Send(user.Email, ...);
// Important business logic
...
}

13. “My focus is to forget the pain of life.
Forget the pain, mock the pain,
reduce it. And laugh.”
Jim Carrey

14. The problem - dependencies
My Code
DB
Files
Files
Files
Files
Services

15. The solution – fake/mock objects
My Code
Fake
Fake
Fake

16. Fake objects using Google Mock
class FakeRestApiClient :public RestApiClient
{
public:
MOCK_METHOD2(HttpPost, void(string&, string&));
MOCK_METHOD1(HttpGet, string(string&));
MOCK_METHOD2(HttpPut, void(string&, string&));
MOCK_METHOD1(HttpDelete, void(string&));
};

17. Injecting fake
objects into
existing code

18. Not all dependency
are created equal
Some are harder/impossible to fake
Non virtual
methods
Hard to
inherit
classes
Static
method
calls
Singletons
Internally
instantiated
Heavy
classes

19. Faking Singletons
class MySingleton {
static std::once_flag onceFlag;
static MySingleton* instance;
public:
static MySingleton* GetInstance() {
std::call_once(onceFlag, [] {
instance = new MySingleton();
});
return instance;
}
private:
MySingleton(){}
}

20. Friend is your friend
class MySingletons;
class Rectangle
{
int width, height;
public:
friend FakeRectangle;
};

21. Problem: un-fakeable methods
• Static methods
• Hard/impossible to instantiate class
• Non-virtual methods
Cannot be inherited == cannot be injected!

22. Using templates for injection
Compile time duck typing a.k.a hi-perf dependency injection
• Can fake unfakeables
• Can fake internally instantiated classes

23. Faking Private and Protected Methods
classFoo
{
public:
virtualbool MyPublicMethod(MyClass* c){...};
protected:
virtualvoid MyProtectedMethod(int a,intb){...};
private:
virtualint MyPrivateMethod(){...}
}

24. Faking Private and Protected Methods
classFoo
{
public:
MOCK_METHOD1(MyPublicMethod,bool(MyClass*));
MOCK_METHOD2(MyProtectedMethod,void(int,int));
MOCK_METHOD0(MyPrivateMethod,int());
}

25. Taking control of existing legacy code
Legacy code

Write tests
Create fake
objects
Swap
dependencies
Refactor &
cleanup
Maintainable
code 

26. Thank you
Dror Helper | @dhelper | http://helpercode.com