Several Reasons to hate MFC
My Life/Just a Thought :
2008. 4. 11. 00:25
Personally, I think MFC failed to grasp the concept of the Object-Oriented Programming paradigm.
MFC provides poor data abstraction and encapsulation. And here are my personal opinions what led to that conclusion.
1. I guess I am never going to understand how the Doc/View Architecture is supposed to work. Especially the part how Documents are created or opened, and how it associates with the views. It involves too much unnecessary details when you can easily implement something similar to the Doc/View architecture by using simple association among classes.
2. What is the difference between Classes that are derived from CDialog, and CFormView. Some of the people who understand MFC better than me might argue with my opinion, but don't they serve the same purpose of displaying whatever there is to? I think I understand the intention of separating the roles of dialogs and views, but I think it was a bad choice. Does the .Net framework distinguish dialog and views?
3. Why are the information of the resources declared in global scope in resource.h and .rc file? Why doesn't the class itself contain the information of the resources? Of course it is possible to make the class contain the information of the resources it contains by using DLGTEMPLATE structure. Creating the dialog template dynamically in memory and loading it at run-time. However, you will have code every single information of each control. For this reason, it is difficult to create static library that contains graphical user interface.
4. I find the MFC library interface to be inconsistent. For example, when parameters of a function must be passed by reference, in some cases, the formal parameter is passed by reference, while the rest uses pointer type parameters.
5. Units differ by the context in which it is being used. Why couldn't they have used pixels for the main unit for every measurement? This really bothers me when I am writing code that creates the dialog template on the fly at run-time.
6. Some features aren't documented on MSDN while Google shows us bunch of undocumented features. Why is that? My guess is that the undocumented features were supposed to be hidden. However, many parts of the undocumented tricks and features can be found on the web.
7. While debugging, you can actually step into the MFC library. What is the intention of letting that possible? I suspect that the library code can be accidentally altered by the programmer. Although it is something which must have been avoided, I cannot imagine debugging my program without stepping into the library. If debugging was only possible by stepping into the library code for some situations, then I think MFC seriously failed to provide nice and neat data abstraction and encapsulation. Or maybe the folks at Microsoft were too lazy to implement exception handling for majority of the possible errors and document them.
8. Simply too complicated...
Yes, MFC is very flexible, hence powerful. But only if you understand every tiny detail correctly. I'm not a very experienced programmer, especially in VC++. That might be the reason why I am complaining about the issues above. The opportunity to work with MFC made me humble and I actually found out that there are many things that I don't know well yet that I used to think I knew well. Some things I pointed out might not be true due to my lack of knowledge and understanding. However, many people may agree that MFC or probably WIN32 API is hard for starters. Or maybe I'm too accustomed to OOP that I cannot stand the complexity of MFC (Although MFC are class based, and uses the OOP paradigm most of you would agree that Java and C# are more OOP oriented, wouldn't you?).
I would like to hear about other people's opinion on MFC. Its strengths and weaknesses. Are you up for it or not???
MFC provides poor data abstraction and encapsulation. And here are my personal opinions what led to that conclusion.
1. I guess I am never going to understand how the Doc/View Architecture is supposed to work. Especially the part how Documents are created or opened, and how it associates with the views. It involves too much unnecessary details when you can easily implement something similar to the Doc/View architecture by using simple association among classes.
2. What is the difference between Classes that are derived from CDialog, and CFormView. Some of the people who understand MFC better than me might argue with my opinion, but don't they serve the same purpose of displaying whatever there is to? I think I understand the intention of separating the roles of dialogs and views, but I think it was a bad choice. Does the .Net framework distinguish dialog and views?
3. Why are the information of the resources declared in global scope in resource.h and .rc file? Why doesn't the class itself contain the information of the resources? Of course it is possible to make the class contain the information of the resources it contains by using DLGTEMPLATE structure. Creating the dialog template dynamically in memory and loading it at run-time. However, you will have code every single information of each control. For this reason, it is difficult to create static library that contains graphical user interface.
4. I find the MFC library interface to be inconsistent. For example, when parameters of a function must be passed by reference, in some cases, the formal parameter is passed by reference, while the rest uses pointer type parameters.
5. Units differ by the context in which it is being used. Why couldn't they have used pixels for the main unit for every measurement? This really bothers me when I am writing code that creates the dialog template on the fly at run-time.
6. Some features aren't documented on MSDN while Google shows us bunch of undocumented features. Why is that? My guess is that the undocumented features were supposed to be hidden. However, many parts of the undocumented tricks and features can be found on the web.
7. While debugging, you can actually step into the MFC library. What is the intention of letting that possible? I suspect that the library code can be accidentally altered by the programmer. Although it is something which must have been avoided, I cannot imagine debugging my program without stepping into the library. If debugging was only possible by stepping into the library code for some situations, then I think MFC seriously failed to provide nice and neat data abstraction and encapsulation. Or maybe the folks at Microsoft were too lazy to implement exception handling for majority of the possible errors and document them.
8. Simply too complicated...
Yes, MFC is very flexible, hence powerful. But only if you understand every tiny detail correctly. I'm not a very experienced programmer, especially in VC++. That might be the reason why I am complaining about the issues above. The opportunity to work with MFC made me humble and I actually found out that there are many things that I don't know well yet that I used to think I knew well. Some things I pointed out might not be true due to my lack of knowledge and understanding. However, many people may agree that MFC or probably WIN32 API is hard for starters. Or maybe I'm too accustomed to OOP that I cannot stand the complexity of MFC (Although MFC are class based, and uses the OOP paradigm most of you would agree that Java and C# are more OOP oriented, wouldn't you?).
I would like to hear about other people's opinion on MFC. Its strengths and weaknesses. Are you up for it or not???
'My Life > Just a Thought' 카테고리의 다른 글
| 무의미한 연봉협상... (2) | 2008.05.19 |
|---|---|
| 어떻게 받아들여야 하는건지... (2) | 2008.05.18 |
| 뒤를 돌아보고 반성해야할 때... (5) | 2008.05.09 |
| 엔지니어로써 바라본 이건희 회장의 퇴진... (6) | 2008.04.22 |
| ▶◀ We will not... Forget (0) | 2008.04.17 |
| [우리 결혼했어요] 솔비>신애>사오리>서인영 (6) | 2008.04.04 |
| 미친소 Six Sigma 필요하다 !!! (0) | 2008.03.10 |
| 숭례문 화재사건의 책임을 누가 질 것인가? (0) | 2008.02.13 |
| 신문기사, 숭례문, 그리고 코리아~ (0) | 2008.02.11 |
| [Maxtor 300GB Network HD] Piece of Junk !!! (0) | 2007.11.14 |
