OOP is driving me crazy!
-
Well, one way is the following: - Change
Client classconstructor to accept aDialog classreference. Store the passed reference as member ofClient class- MakeDialog classpublic methods to allow access to relevant class data. (a brutal alternative to this step is declaringClient classfriend ofDialog class). For instance: // Clientclass Client
{
Dialog & m_dlg;
public:
Client( Dialog & dialog):m_dlg(dialog){}
...
}// Dialog
class Dialog
{
public:
setLabelText(LPCTSTR szText)
{
...
}
...
}and then, somewhere in your code:
Dialog dlg;
...
Client client(dlg);
...and, finally, somewhere in
Clientcode:m_dlg.setLabelText(_T("packet received"));
:)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
Yes, but Dialog needs Client too... They both need each other, and with the include guards that's not possible. And if I remove the include guards I get infinite error messages by the compiler... :(( Any more ideas? Thanks!
Windows Calculator told me I will die at 28. :(
-
Hello everyone! I've been coding in C for a long time. Now I' starting to get into C++. Well, my last 2 projects which I started in C++ I had to convert to C because I couldn't figure out how to use classes. Take for example my current situation: There is a Dialog class, which holds all of the GUI functionality of my program. The Dialog class contains an object of type Client, which holds all of the networking functionality. Well, Client wants to interact with a GUI control inside Dialog. But that's not possible because C++ doesn't allow Client to know anything about Dialog. So how would I solve that? If you can answer, I will thank you for life. :) Thanks in advance!
Windows Calculator told me I will die at 28. :(
Lord Kixdemp wrote:
C++ doesn't allow Client to know anything about Dialog.
Here's the clue. C++ allows Client only to know that Dialog is a Dialog, i.e the public interface of the Dialog class. This is painful because it restricts what Client knows and you have to make everything about Dialog you want accessible available as part of the public interface but it's great in the long term because Client doesn't care which Dilaog it is or even what sort of Dialog as long as it is a Dialog class the code will work. Do it in C and it'll be done in half the time and obselete and unmaintainable in months. In C++ it might take a while to do but you'll still be using bits of it when you're old and grey. :) I port a lot of C code to C++ so here's a method you might be able to simulate if you find it easier to think in C. I take each C source file and turn it into a class. Every file static variable becomes a member variable, every function extern(ed) in any other file becomes a public member function. Every little utility function not extern(ed) becomes a private member function. Then I create one single file static instance of the class. This gets me a half way house between C and C++ and by the time a whole project has been tranformed like this I can see what the public interfaces need to be and how the instancing of each class should be controlled. What owns what. Eventually all the file level statics disappear and the large classes are reworked into objects that match the required instancing pattern. OOP is not so hard after all. :)
Nothing is exactly what it seems but everything with seems can be unpicked.
-
Hello everyone! I've been coding in C for a long time. Now I' starting to get into C++. Well, my last 2 projects which I started in C++ I had to convert to C because I couldn't figure out how to use classes. Take for example my current situation: There is a Dialog class, which holds all of the GUI functionality of my program. The Dialog class contains an object of type Client, which holds all of the networking functionality. Well, Client wants to interact with a GUI control inside Dialog. But that's not possible because C++ doesn't allow Client to know anything about Dialog. So how would I solve that? If you can answer, I will thank you for life. :) Thanks in advance!
Windows Calculator told me I will die at 28. :(
I deserve harsh punishment for not Googling first. :mad:
-
Hello everyone! I've been coding in C for a long time. Now I' starting to get into C++. Well, my last 2 projects which I started in C++ I had to convert to C because I couldn't figure out how to use classes. Take for example my current situation: There is a Dialog class, which holds all of the GUI functionality of my program. The Dialog class contains an object of type Client, which holds all of the networking functionality. Well, Client wants to interact with a GUI control inside Dialog. But that's not possible because C++ doesn't allow Client to know anything about Dialog. So how would I solve that? If you can answer, I will thank you for life. :) Thanks in advance!
Windows Calculator told me I will die at 28. :(
I deserve harsh punishment for not Googling first. :mad: http://www.thescripts.com/forum/thread63131.html[^] Thanks all very much for your time!
-
Yes, but Dialog needs Client too... They both need each other, and with the include guards that's not possible. And if I remove the include guards I get infinite error messages by the compiler... :(( Any more ideas? Thanks!
Windows Calculator told me I will die at 28. :(
You can do stuff like this...
//----------------------------- //Dialog.h //forward declaration class CClient; /*Dialog can decalre pointers to CClient only and no code that uses them in the header file*/ class CDialog { public: CDialog(CClient* pClient); private: CClient* m_pClient; };//----------------------------- //Client.h #include "Dialog.h" class CClient { //Client can use anything from Dialog CClient(CDialog& aDialog) : m_Dialog(aDialog) { } private: CDialog& m_Dialog };//----------------------------- //Dialog.cpp #include "Client.h"//This inclues Dialog.h as well //Now you can write Dialog code that does stuff with Clients :-) CDialog::CDialog(CClient* pClient) { m_pClient = pClient; }Nothing is exactly what it seems but everything with seems can be unpicked.
-
Yes, but Dialog needs Client too... They both need each other, and with the include guards that's not possible. And if I remove the include guards I get infinite error messages by the compiler... :(( Any more ideas? Thanks!
Windows Calculator told me I will die at 28. :(
Well, this is not a big problem. For instance, you can use pointers instead of references and avoid including headers inside each other exploiting class deferred declaration:
// this is B.h
#pragma once
class A; // class a deferred declaration
class B
{
A * _pA;
public:
B(A * pA):_pA(pA){}
public:
~B(void){};
};Note I've not included
A.hin theclass Bheader. Of course you have to includeA.hinsideB.cppto do something useful with the_pApointer, but this will be not a problem anymore. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
-
Hello everyone! I've been coding in C for a long time. Now I' starting to get into C++. Well, my last 2 projects which I started in C++ I had to convert to C because I couldn't figure out how to use classes. Take for example my current situation: There is a Dialog class, which holds all of the GUI functionality of my program. The Dialog class contains an object of type Client, which holds all of the networking functionality. Well, Client wants to interact with a GUI control inside Dialog. But that's not possible because C++ doesn't allow Client to know anything about Dialog. So how would I solve that? If you can answer, I will thank you for life. :) Thanks in advance!
Windows Calculator told me I will die at 28. :(
One possible solution is to send messages to the dialog. Your client needs the target Window (CWnd*) and you can use the SendMessage() , or I suggest the PostMessage() API because it is non blocking. Another way are global objects and structures or callbacks. Interesting and important is to use the Timer-function to execute regurarly some actions!!! Search for WM_TIMER
Greetings from Germany
-
Well, one way is the following: - Change
Client classconstructor to accept aDialog classreference. Store the passed reference as member ofClient class- MakeDialog classpublic methods to allow access to relevant class data. (a brutal alternative to this step is declaringClient classfriend ofDialog class). For instance: // Clientclass Client
{
Dialog & m_dlg;
public:
Client( Dialog & dialog):m_dlg(dialog){}
...
}// Dialog
class Dialog
{
public:
setLabelText(LPCTSTR szText)
{
...
}
...
}and then, somewhere in your code:
Dialog dlg;
...
Client client(dlg);
...and, finally, somewhere in
Clientcode:m_dlg.setLabelText(_T("packet received"));
:)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
-
led mike wrote:
Really, that's your advice?
Yes.
led mike wrote:
Are you kidding me!
Why do you think that? :) OK you're right, in my proposal there is (almost ;P ) no way to avoid the troublesome interdependency of the headers. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
modified on Tuesday, December 11, 2007 11:12:43 AM
-
I deserve harsh punishment for not Googling first. :mad: http://www.thescripts.com/forum/thread63131.html[^] Thanks all very much for your time!
Lord Kixdemp wrote:
I deserve harsh punishment for not Googling first.
And you will likely receive harsh punishment if you tightly couple a business object to a view. Your punishment will be in the form of dealing with the technical debt[^] of a poor design. OOD is a tool that can solve problems of software development like hard to maintain and inflexible code. Notice I said it "can" solve those problems, or a sub optimal design, like one that would tightly couple business classes to view classes, could result in "creating" those same problems. There is much information available on the subject of Object Oriented Design. I strongly suggest you take some time to become familiar with things like best practices and principles of object oriented design. You might try some articles or tutorials and for sure get introduced to Software Design Patterns[^]. Good luck
-
You can do stuff like this...
//----------------------------- //Dialog.h //forward declaration class CClient; /*Dialog can decalre pointers to CClient only and no code that uses them in the header file*/ class CDialog { public: CDialog(CClient* pClient); private: CClient* m_pClient; };//----------------------------- //Client.h #include "Dialog.h" class CClient { //Client can use anything from Dialog CClient(CDialog& aDialog) : m_Dialog(aDialog) { } private: CDialog& m_Dialog };//----------------------------- //Dialog.cpp #include "Client.h"//This inclues Dialog.h as well //Now you can write Dialog code that does stuff with Clients :-) CDialog::CDialog(CClient* pClient) { m_pClient = pClient; }Nothing is exactly what it seems but everything with seems can be unpicked.
Matthew Faithfull wrote:
You can do stuff like this...
Yeah I could also create a function that takes as a parameter a reference to a pointer to a pointer of a structure that contains a union that has a member that is a pointer to a pointer to a structure that contains a member that is a pointer to a function that takes as a parameter.... Not everything you can do is something you should do. Take a clue from best practices and principles of object oriented design and software design patterns. Or don't .... whatever, but try not to give bad advice to beginners that may still have a hope of becoming capable of creating something other than technical debt.
-
Matthew Faithfull wrote:
You can do stuff like this...
Yeah I could also create a function that takes as a parameter a reference to a pointer to a pointer of a structure that contains a union that has a member that is a pointer to a pointer to a structure that contains a member that is a pointer to a function that takes as a parameter.... Not everything you can do is something you should do. Take a clue from best practices and principles of object oriented design and software design patterns. Or don't .... whatever, but try not to give bad advice to beginners that may still have a hope of becoming capable of creating something other than technical debt.
Or you could take your own advice :) The technique I described of forward declaring a related class and using only the declaration in the header so that both classes can 'know' about each other is both standard, as in used everywhere, and extremely useful as in you're pretty stuffed wihtout it. I don't know or care what the OPs objects do I only know about the interface he's given me, the question. by all means post a better solution, more appropriate to a beginner, easy to understand, more general, more useful and wiser in every way. I'd certainly suggest doing so before criticising the perfectly reasonable advice already posted or no one including the OP is likely to take any notice.:|
Nothing is exactly what it seems but everything with seems can be unpicked.
-
Or you could take your own advice :) The technique I described of forward declaring a related class and using only the declaration in the header so that both classes can 'know' about each other is both standard, as in used everywhere, and extremely useful as in you're pretty stuffed wihtout it. I don't know or care what the OPs objects do I only know about the interface he's given me, the question. by all means post a better solution, more appropriate to a beginner, easy to understand, more general, more useful and wiser in every way. I'd certainly suggest doing so before criticising the perfectly reasonable advice already posted or no one including the OP is likely to take any notice.:|
Nothing is exactly what it seems but everything with seems can be unpicked.
Matthew Faithfull wrote:
by all means post a better solution
I already did before I replied to your post.
Matthew Faithfull wrote:
Or you could take your own advice
If you were at all familiar with my posts you would not have made that statement. I am one of the few people on the site that attempt to introduce people to the benefits of object oriented design.
Matthew Faithfull wrote:
I don't know or care what the OPs objects do
You really didn't need to say that, it was very clear from your original post. I now return you to your regularly scheduled activity of manufacturing technical debt.
-
Matthew Faithfull wrote:
by all means post a better solution
I already did before I replied to your post.
Matthew Faithfull wrote:
Or you could take your own advice
If you were at all familiar with my posts you would not have made that statement. I am one of the few people on the site that attempt to introduce people to the benefits of object oriented design.
Matthew Faithfull wrote:
I don't know or care what the OPs objects do
You really didn't need to say that, it was very clear from your original post. I now return you to your regularly scheduled activity of manufacturing technical debt.
led mike wrote:
I already did before I replied to your post.
:confused:Strangely it seems to be absent form the forum.
led mike wrote:
If you were at all familiar with my posts you would not have made that statement. I am one of the few people on the site that attempt to introduce people to the benefits of object oriented design.
That wasn't the part of your advice I was refering to. I'm sure your OOP skills are second to none and you frequently point people in the right direction.
led mike wrote:
I now return you to your regularly scheduled activity of manufacturing technical debt.
:laugh: Don't assume I know less than you'd like me to just because we understand the OPs needs differently. I haven't manufactured any technical debt in years. :laugh:
Nothing is exactly what it seems but everything with seems can be unpicked.
-
Matthew Faithfull wrote:
You can do stuff like this...
Yeah I could also create a function that takes as a parameter a reference to a pointer to a pointer of a structure that contains a union that has a member that is a pointer to a pointer to a structure that contains a member that is a pointer to a function that takes as a parameter.... Not everything you can do is something you should do. Take a clue from best practices and principles of object oriented design and software design patterns. Or don't .... whatever, but try not to give bad advice to beginners that may still have a hope of becoming capable of creating something other than technical debt.
-
led mike wrote:
I already did before I replied to your post.
:confused:Strangely it seems to be absent form the forum.
led mike wrote:
If you were at all familiar with my posts you would not have made that statement. I am one of the few people on the site that attempt to introduce people to the benefits of object oriented design.
That wasn't the part of your advice I was refering to. I'm sure your OOP skills are second to none and you frequently point people in the right direction.
led mike wrote:
I now return you to your regularly scheduled activity of manufacturing technical debt.
:laugh: Don't assume I know less than you'd like me to just because we understand the OPs needs differently. I haven't manufactured any technical debt in years. :laugh:
Nothing is exactly what it seems but everything with seems can be unpicked.
Matthew Faithfull wrote:
Strangely it seems to be absent form the forum.
I can see it. I'm afraid to even try the
Permalinkfeature on the "new and destroyed" version of CP! :-DMatthew Faithfull wrote:
I haven't manufactured any technical debt in years.
So you haven't developed any software in years? It's all but impossible to keep from creating technical debt when developing software. It's just a matter of degrees and managing risk in most cases.
Matthew Faithfull wrote:
just because we understand the OPs needs differently.
Fair enough, I read the OP as being interested in the design aspects of his problem. It's very rare to see anyone posting something here that even hints at an interest in design issues.
-
IMHO there is nothig bad in his proposed solution. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
-
Matthew Faithfull wrote:
Strangely it seems to be absent form the forum.
I can see it. I'm afraid to even try the
Permalinkfeature on the "new and destroyed" version of CP! :-DMatthew Faithfull wrote:
I haven't manufactured any technical debt in years.
So you haven't developed any software in years? It's all but impossible to keep from creating technical debt when developing software. It's just a matter of degrees and managing risk in most cases.
Matthew Faithfull wrote:
just because we understand the OPs needs differently.
Fair enough, I read the OP as being interested in the design aspects of his problem. It's very rare to see anyone posting something here that even hints at an interest in design issues.
led mike wrote:
So you haven't developed any software in years?
Sometimes it feels like it on this project but no, I reckon I've removed as much technical debt as I've added certainly in the last few years, 2 working on a great product where it's easy enough to add code with an absolute minimum of the usual risks. Before that the previous product I worked on was so bad that pretty much every change I made removed more problems that it created. Fair enough, I read the OP as being a C programmer doing nothing resembling actual OOP but wanting to use C++, to head in the right direction and needing a bridge from C to C++ thinking before diving in with patterns. I am quite familiar with the GOF and all their works. I've even posted a patterns article[^] which you're very welcome to shred if you so wish. :)
Nothing is exactly what it seems but everything with seems can be unpicked.
-
Lord Kixdemp wrote:
I deserve harsh punishment for not Googling first.
And you will likely receive harsh punishment if you tightly couple a business object to a view. Your punishment will be in the form of dealing with the technical debt[^] of a poor design. OOD is a tool that can solve problems of software development like hard to maintain and inflexible code. Notice I said it "can" solve those problems, or a sub optimal design, like one that would tightly couple business classes to view classes, could result in "creating" those same problems. There is much information available on the subject of Object Oriented Design. I strongly suggest you take some time to become familiar with things like best practices and principles of object oriented design. You might try some articles or tutorials and for sure get introduced to Software Design Patterns[^]. Good luck
Wow, looks like there's more to software development than just coding. :wtf: I looked up for some tutorials, and found this bunch: http://www.devdaily.com/Dir/OOA_OOD/Patterns/Tutorials/[^] You seem to know about the subject, so would you mind pointing out which of those is the best to start with? :) Thanks!
Windows Calculator told me I will die at 28. :(
-
Don't bother trying to convince me, just go right to someone like Kent Beck with your opinion.
led mike wrote:
Don't bother trying to convince me
Oh, I don't need (and don't want) to do that. I just expressed my own opinion (maybe ad (dis)advantage ;) of other people reading the thread)
led mike wrote:
just go right to someone like Kent Beck with your opinion
Good designs depend on a lot of factors, the less important being authority. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
