This is going to be too much to fit in one post. So lets start with the most provocative.
I'm over Constructors and Deconstructors
It's such a staple of OOP and yet I could seriously do without them now. If you're like me you learned these are great places to create/delete required objects, open/close files and all that stuff. But it just causes trouble.
Here's a typical example:
Great! What could be wrong with that? We'll there's two things.
1. You want to customise things in a child class
Ideally you shouldn't need to mess with the parent. Maybe due to some rules on shared code you can't change the parent (easily). But if you want anotherObject to be CustomObject and use a different filename you end up with this crap:
Ugh. It's terrible! You'd never do this on a normal 'virtual' function. You'd just not call the parent. But with a constructor and deconstructor you don't have a choice.
2. You're running unit tests
Don't tell me you're not writing tests! But you don't want the object opening a file. That means you have to mess with a file just to run a test case. And perhaps CustomObject does stuff you don't want too. But you can't change it to never construct. Both will happen no matter what you try and do with a child class. So you're in the shit now.
So what can you do?
I'm half tempted to replace my constructors with a macro (except they're evil) as they are all starting to look like this:
There's times when the construction order wont let you do that. But then you have to pass in a factory object and that can open a whole new can of worms.
Most of these problems are common to OO languages. But it's just one reason why C++ sucks.
I'm over Constructors and Deconstructors
It's such a staple of OOP and yet I could seriously do without them now. If you're like me you learned these are great places to create/delete required objects, open/close files and all that stuff. But it just causes trouble.
Here's a typical example:
MyObject()
{
anotherObject = new AnotherObject();
fileHandle = open("configfile.xml");
}
~MyObject()
{
close(fileHandle);
delete anotherObject;
}
Great! What could be wrong with that? We'll there's two things.
1. You want to customise things in a child class
Ideally you shouldn't need to mess with the parent. Maybe due to some rules on shared code you can't change the parent (easily). But if you want anotherObject to be CustomObject and use a different filename you end up with this crap:
MyObjectChild() : MyObject()
{
delete anotherObject;
anotherObject = new CustomObject();
close(fileHandle);
fileHandle = open("myfile.xml");
}
Ugh. It's terrible! You'd never do this on a normal 'virtual' function. You'd just not call the parent. But with a constructor and deconstructor you don't have a choice.
2. You're running unit tests
Don't tell me you're not writing tests! But you don't want the object opening a file. That means you have to mess with a file just to run a test case. And perhaps CustomObject does stuff you don't want too. But you can't change it to never construct. Both will happen no matter what you try and do with a child class. So you're in the shit now.
So what can you do?
I'm half tempted to replace my constructors with a macro (except they're evil) as they are all starting to look like this:
MyObject(AnotherObject * _anotherObject, int _fileHandle) :
anotherObject(_anotherObject),
fileHandle(_fileHandle)
{
}
There's times when the construction order wont let you do that. But then you have to pass in a factory object and that can open a whole new can of worms.
Most of these problems are common to OO languages. But it's just one reason why C++ sucks.
Comments
Post a Comment