Do you embed classes within classes?
-
I started my software development career using FORTRAN, taught myself C, suffered through Pascal and despise Visual Basic. I'm an EE that just learned how to do this. Back in the beginning, there were no IDEs just text editors, so I naturally developed the habit of putting one function in one file. As I moved on to C++, I continued this style with my class development - one class per file. I suppose I picked up this style from the people I worked with, early source control systems I used (CMS/MMS anyone?) and what not. Now I admit I am no C++ guru. I have seen people on stack overflow answer a C++ question with so much mind numbing detail that my eyes glaze. I view some or most of the esoteric aspects of c++ (like operator overloading) as dubious at best. Sounds good initially but later on in maintenance, ugh. So, coding style question - do you embed classes within classes? I suppose if the object is never used outside of it's main file, it sort of makes sense. But it makes it a $itch to track things down. Then, other modules that include the header file for the parent start referencing the embedded classes, and it becomes spaghetti code. I know it's valid C++, but.... Thoughts? I'm probably just being a curmudgeon. Currently doing battle with lifting a VC6 project to VS2022. To say it's "interesting" is putting it lightly but that's for another post.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Yes. exempli gratia a method returns data related to the class. What better way than via a class. What better place to declare the returned class than embedded.
-
I started my software development career using FORTRAN, taught myself C, suffered through Pascal and despise Visual Basic. I'm an EE that just learned how to do this. Back in the beginning, there were no IDEs just text editors, so I naturally developed the habit of putting one function in one file. As I moved on to C++, I continued this style with my class development - one class per file. I suppose I picked up this style from the people I worked with, early source control systems I used (CMS/MMS anyone?) and what not. Now I admit I am no C++ guru. I have seen people on stack overflow answer a C++ question with so much mind numbing detail that my eyes glaze. I view some or most of the esoteric aspects of c++ (like operator overloading) as dubious at best. Sounds good initially but later on in maintenance, ugh. So, coding style question - do you embed classes within classes? I suppose if the object is never used outside of it's main file, it sort of makes sense. But it makes it a $itch to track things down. Then, other modules that include the header file for the parent start referencing the embedded classes, and it becomes spaghetti code. I know it's valid C++, but.... Thoughts? I'm probably just being a curmudgeon. Currently doing battle with lifting a VC6 project to VS2022. To say it's "interesting" is putting it lightly but that's for another post.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
do you embed classes within classes?
Yes, if appropriate. The maxim "the right tool for the job" applies. I manage visibility with
private/protectedas necessary if the embedded class is only used internally by the surrounding class. An example would be elements in a data structure used within the surrounding class. If an embedded class is public, then it is embedded because it has relevance only in relation to the surrounding class. The example here would be the embedded class contains properties and state of interest to users of the surrounding class and it's either cumbersome or infeasible to have the surrounding class supply those values itself.Software Zen:
delete this; -
I started my software development career using FORTRAN, taught myself C, suffered through Pascal and despise Visual Basic. I'm an EE that just learned how to do this. Back in the beginning, there were no IDEs just text editors, so I naturally developed the habit of putting one function in one file. As I moved on to C++, I continued this style with my class development - one class per file. I suppose I picked up this style from the people I worked with, early source control systems I used (CMS/MMS anyone?) and what not. Now I admit I am no C++ guru. I have seen people on stack overflow answer a C++ question with so much mind numbing detail that my eyes glaze. I view some or most of the esoteric aspects of c++ (like operator overloading) as dubious at best. Sounds good initially but later on in maintenance, ugh. So, coding style question - do you embed classes within classes? I suppose if the object is never used outside of it's main file, it sort of makes sense. But it makes it a $itch to track things down. Then, other modules that include the header file for the parent start referencing the embedded classes, and it becomes spaghetti code. I know it's valid C++, but.... Thoughts? I'm probably just being a curmudgeon. Currently doing battle with lifting a VC6 project to VS2022. To say it's "interesting" is putting it lightly but that's for another post.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
I mostly do C# these days. But I find that when I am designing a dialog box for a program, I usually need more than a single primitive value returned. What I seem to end up doing is writing an embedded class to handle all the returning data. I make it an embedded class because I can keep it associated with that dialog box. Using a class gives it an instance that doesn't vanish the moment the dialog closes. There have been a few occasions when I've decided that an embedded class was a good solution as a class to handle multiple issues in a project. When I get to that point, I usually elect to change the class from embedded to a separate file.
-
I started my software development career using FORTRAN, taught myself C, suffered through Pascal and despise Visual Basic. I'm an EE that just learned how to do this. Back in the beginning, there were no IDEs just text editors, so I naturally developed the habit of putting one function in one file. As I moved on to C++, I continued this style with my class development - one class per file. I suppose I picked up this style from the people I worked with, early source control systems I used (CMS/MMS anyone?) and what not. Now I admit I am no C++ guru. I have seen people on stack overflow answer a C++ question with so much mind numbing detail that my eyes glaze. I view some or most of the esoteric aspects of c++ (like operator overloading) as dubious at best. Sounds good initially but later on in maintenance, ugh. So, coding style question - do you embed classes within classes? I suppose if the object is never used outside of it's main file, it sort of makes sense. But it makes it a $itch to track things down. Then, other modules that include the header file for the parent start referencing the embedded classes, and it becomes spaghetti code. I know it's valid C++, but.... Thoughts? I'm probably just being a curmudgeon. Currently doing battle with lifting a VC6 project to VS2022. To say it's "interesting" is putting it lightly but that's for another post.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
I always try to use the right tool for the right job.
-
As a somewhat handicapped non- queen's English speaker I get puzzled by some expression. I have done some embedded processor hobby type projects, and currently I am struggling with child classes as members of a parent class. I do see the differences , but mixing up these terms , or inventing new one (?) is frustrating. Does it really makes much difference not calling classes as "member of " as are other member variables called ? I have never seen usage of term "embedded variable "...
Different languages have different terms that are the same thing at an abstract level. Delphi has a concept of nested methods, which are either a function or procedure defined inside another (Delphi is based on Pascal, and this was explained in detail in a prior post). C# allows nested classes, where one class has another defined inside it. As others have said, this really should only be done if the nested/inner class is marked as private so only the outer class can access it. I'm avoiding the terms parent/child because those are usually used with inheritance, and this discussion has nothing to do with inheritance. Embedded variable? It's a new one for me. I googled it:
Quote:
An embedded variable in programming is not predetermined and changes, so it can't be entered ahead of time.
Bond Keep all things as simple as possible, but no simpler. -said someone, somewhere
-
As a somewhat handicapped non- queen's English speaker I get puzzled by some expression. I have done some embedded processor hobby type projects, and currently I am struggling with child classes as members of a parent class. I do see the differences , but mixing up these terms , or inventing new one (?) is frustrating. Does it really makes much difference not calling classes as "member of " as are other member variables called ? I have never seen usage of term "embedded variable "...
-
charlieg wrote:
do you embed classes within classes?
Yes, if appropriate. The maxim "the right tool for the job" applies. I manage visibility with
private/protectedas necessary if the embedded class is only used internally by the surrounding class. An example would be elements in a data structure used within the surrounding class. If an embedded class is public, then it is embedded because it has relevance only in relation to the surrounding class. The example here would be the embedded class contains properties and state of interest to users of the surrounding class and it's either cumbersome or infeasible to have the surrounding class supply those values itself.Software Zen:
delete this;I see that as a COMPLETE contradiction of encapsulation, but I freely admit to despising embedded classes. This might be because every series of embedded classes I have encountered show no reason to exist other than to be cute. The code base I am working on actually has embedded classes within other classes that are all public. So my thought is wtf, why not make it obvious?
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
I always try to use the right tool for the right job.
-
I mostly do C# these days. But I find that when I am designing a dialog box for a program, I usually need more than a single primitive value returned. What I seem to end up doing is writing an embedded class to handle all the returning data. I make it an embedded class because I can keep it associated with that dialog box. Using a class gives it an instance that doesn't vanish the moment the dialog closes. There have been a few occasions when I've decided that an embedded class was a good solution as a class to handle multiple issues in a project. When I get to that point, I usually elect to change the class from embedded to a separate file.
Question: explain to me how putting data in an embedded class solves any problem? If the instance of the dialog (which is an object) sticks around, then the public data is still available. Embedding an object within an object seems over complicated to me. Double encapsulation?
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
Question: explain to me how putting data in an embedded class solves any problem? If the instance of the dialog (which is an object) sticks around, then the public data is still available. Embedding an object within an object seems over complicated to me. Double encapsulation?
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
I'll have to look at some of my project code and get back with you, as it half past midnight here, and I am a bit fuzzy on why. I know that the way I write my dialogs aren't quite as trivial as textbook examples, and I have to look and see why. But what I think I was doing was not so much as embedded a class within a class, but simply putting my data class on the end of the dialogbox class, initially, rather than having a separate file for the data class. It may relate to my wanting a dialog box that had an Apply button implemented in addition to the usual OK and Cancel buttons. It may be that my dialog box does something complicated and has to stay open and effect the target form with changes as I make them on the dialog without closing and reopening the dialog repeatedly until I get the combination I want.
-
I'll have to look at some of my project code and get back with you, as it half past midnight here, and I am a bit fuzzy on why. I know that the way I write my dialogs aren't quite as trivial as textbook examples, and I have to look and see why. But what I think I was doing was not so much as embedded a class within a class, but simply putting my data class on the end of the dialogbox class, initially, rather than having a separate file for the data class. It may relate to my wanting a dialog box that had an Apply button implemented in addition to the usual OK and Cancel buttons. It may be that my dialog box does something complicated and has to stay open and effect the target form with changes as I make them on the dialog without closing and reopening the dialog repeatedly until I get the combination I want.
Okay, I'm feeling your direction. It seems like you separate all of your dialog processing from any data processing. MVC light? Anyway, my dialogs tend to just do things. The times I need to obtain data from a dialog, I'll either make it publicly available or add a wrapper method to the dialog class. Interested in your follow up comments.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
Okay, I'm feeling your direction. It seems like you separate all of your dialog processing from any data processing. MVC light? Anyway, my dialogs tend to just do things. The times I need to obtain data from a dialog, I'll either make it publicly available or add a wrapper method to the dialog class. Interested in your follow up comments.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Perhaps a dialog's returning a custom data class wasn't the best argument. I think I have a better argument for an embedded class, anyway. I'm working on a class that programmatically displays rectangles of specific color samples, and the user is expected to click on the particular rectangle to select a color. OK, nothing special about that. I am displaying the colors in a matrix of rectangles that are programmatically generated panels, given a generic List of colors that I want to present. After I got deep into the coding, I decided I wanted to have a border around every rectangle, where the color of the border signified which palette the color was in. Not that there are expected to be a lot of palettes, maybe 1, 2 or 3. But I ran into a problem: the panel control doesn't have a means to define the color of it's border. I posed that problem to ChatGPT, and it suggested I write a custom Panel class that extends the standard panel class and showed me how I could override paint to put a border of any specified color around the Panels I am creating. I don't plan to use this custom panel class anywhere else, it is short and to the point, and there seems no reason yet for having it in a stand-alone file. Steve
-
Perhaps a dialog's returning a custom data class wasn't the best argument. I think I have a better argument for an embedded class, anyway. I'm working on a class that programmatically displays rectangles of specific color samples, and the user is expected to click on the particular rectangle to select a color. OK, nothing special about that. I am displaying the colors in a matrix of rectangles that are programmatically generated panels, given a generic List of colors that I want to present. After I got deep into the coding, I decided I wanted to have a border around every rectangle, where the color of the border signified which palette the color was in. Not that there are expected to be a lot of palettes, maybe 1, 2 or 3. But I ran into a problem: the panel control doesn't have a means to define the color of it's border. I posed that problem to ChatGPT, and it suggested I write a custom Panel class that extends the standard panel class and showed me how I could override paint to put a border of any specified color around the Panels I am creating. I don't plan to use this custom panel class anywhere else, it is short and to the point, and there seems no reason yet for having it in a stand-alone file. Steve
okay, I can see that a private class that is used in that one location. what I'm fighting with is that everything is public.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
As a somewhat handicapped non- queen's English speaker I get puzzled by some expression. I have done some embedded processor hobby type projects, and currently I am struggling with child classes as members of a parent class. I do see the differences , but mixing up these terms , or inventing new one (?) is frustrating. Does it really makes much difference not calling classes as "member of " as are other member variables called ? I have never seen usage of term "embedded variable "...
-
I started my software development career using FORTRAN, taught myself C, suffered through Pascal and despise Visual Basic. I'm an EE that just learned how to do this. Back in the beginning, there were no IDEs just text editors, so I naturally developed the habit of putting one function in one file. As I moved on to C++, I continued this style with my class development - one class per file. I suppose I picked up this style from the people I worked with, early source control systems I used (CMS/MMS anyone?) and what not. Now I admit I am no C++ guru. I have seen people on stack overflow answer a C++ question with so much mind numbing detail that my eyes glaze. I view some or most of the esoteric aspects of c++ (like operator overloading) as dubious at best. Sounds good initially but later on in maintenance, ugh. So, coding style question - do you embed classes within classes? I suppose if the object is never used outside of it's main file, it sort of makes sense. But it makes it a $itch to track things down. Then, other modules that include the header file for the parent start referencing the embedded classes, and it becomes spaghetti code. I know it's valid C++, but.... Thoughts? I'm probably just being a curmudgeon. Currently doing battle with lifting a VC6 project to VS2022. To say it's "interesting" is putting it lightly but that's for another post.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Actually, I often do. A classic example is defining an Iterator class for a container type. It makes more sense to have the Iterator class definition be part of the container class definition (and hence called MyVector::Iterator, for example, than to create a separate MyVectorIterator, and typedef the Iterator type in MyVector. Another example is a Pimpl pattern, although in this case the embedded class is just a declaration on the public interface, and the actual definition is in the implementation file.
-
I started my software development career using FORTRAN, taught myself C, suffered through Pascal and despise Visual Basic. I'm an EE that just learned how to do this. Back in the beginning, there were no IDEs just text editors, so I naturally developed the habit of putting one function in one file. As I moved on to C++, I continued this style with my class development - one class per file. I suppose I picked up this style from the people I worked with, early source control systems I used (CMS/MMS anyone?) and what not. Now I admit I am no C++ guru. I have seen people on stack overflow answer a C++ question with so much mind numbing detail that my eyes glaze. I view some or most of the esoteric aspects of c++ (like operator overloading) as dubious at best. Sounds good initially but later on in maintenance, ugh. So, coding style question - do you embed classes within classes? I suppose if the object is never used outside of it's main file, it sort of makes sense. But it makes it a $itch to track things down. Then, other modules that include the header file for the parent start referencing the embedded classes, and it becomes spaghetti code. I know it's valid C++, but.... Thoughts? I'm probably just being a curmudgeon. Currently doing battle with lifting a VC6 project to VS2022. To say it's "interesting" is putting it lightly but that's for another post.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.