class-design

While cleaning some code today written by someone else, I changed the access modifier from Public to Private on a class variable/member/field. I expected a long list of compiler errors that I use to "refactor/rework/review" the code that used this variable. Imagine my surprise when I didn't get any errors. After reviewing, it turns out that another instance of the Class can access the private members of another instance declared within the Class. Totally unexcepted. Is this normal? I been coding in .NET since the beginning and never ran into this issue, nor read about it. I may have stumbled

I have a class diagram , I want that to draw it in some tool which can generate native C++ out of it , I wish to have design first approach to test the various data structures I am designing for my application A lot of tools can make C++ code out of UML diagrams. Try Software Ideas Modeller for example, it's a great UML tool, and it's free for non-commercial use. Also, wiki has a list of UML tools. You can sort them by "languages generated" column to check what they do support and chose the one that you will like. You can also try UMLET for your work. You can seach mofre on google by typing

I've seen this de facto standard in many places in many languages, but I've never understood it - why put your private fields and methods at the top of a class declaration? Metaphorically it seems like private things should be located at the bottom (hidden) and everything public should be at the top, so that when you read through the class top to bottom you first see the public interface then the inner workings. What is the reasoning behind this? EDIT: Just to clarify, I don't mean the practice of declaring all members at the top of the class, but of putting private members/methods at the top

In Rastertek DirectX tutorials they have empty constructors and destructors and instead use initialize() and shutdown() functions for objects initialization and cleaning up. After using this design for a while I can somewhat understand the benefits of having an initialize() method, but I can't see how using a shutdown() method is any better than putting all the clean-up code in the destructor. The reason they provide is the following: You will also notice I don't do any object clean up in the class destructor. I instead do all my object clean up in the Shutdown function you will see further

I have a simple, low-level container class that is used by a more high-level file class. Basically, the file class uses the container to store modifications locally before saving a final version to an actual file. Some of the methods, therefore, carry directly over from the container class to the file class. (For example, Resize() .) I've just been defining the methods in the file class to call their container class variants. For example: void FileClass::Foo() { ContainerMember.Foo(); } This is, however, growing to be a nuisance. Is there a better way to do this? Here's a simplified example:

I personally don't have my entities implement interfaces. For a Task class I wouldn't have ITask that just had the same properties defined on it. I've seen it done a few times though, so I'm wondering where that advice comes from, and what benefits you get from it. If you're using an ORM then the argument that says "I can change my data access" is irrelevent, so what other reason is there for doing this? UPDATE: A good point was made in the comments about INotifyPropertyChanged . That wasn't my point though - I'm talking about having something like this: public interface ITask { int Id { get;