class-design

问题 I've noticed a variety of @interface declarations for Objective-c classes. I'd like to understand why developers declare @interface in the following ways: // in the .h file @interface MyClass : NSObject // ... @end // in the .m file (what's the purpose of the parens?) @interface MyClass () // more property declarations which seem like they can go in the .h file @end // again in the .m file (what's the purpose of private?) @interface MyClass (Private) // some method declarations @end 回答1: This

问题 Those of us who have seen the beauty of STL try to use it as much as possible, and also encourage others to use it wherever we see them using raw pointers and arrays . Scott Meyers have written a whole book on STL, with title Effective STL. Yet what happened to the developers of ifstream that they preferred char* over std::string . I wonder why the first parameter of ifstream::open() is of type const char* , instead of const std::string & . Please have a look at it's signature: void open

问题 My questions are: When should we use value types and when reference types? What are the advantages and disadvantages of one over other? What if one uses reference types everywhere? Is there any harm in it? Please also discuss advantages and disadvantages of each one. I want to understand that as well. 回答1: There seems to be a lot of confusion over this, and Jon Skeet does a good job of clearing it up in his book "C# In Depth, 2nd Ed." (section 2.3). My personal approach, which may or may not

问题 If you want to associate some constant value with a class, here are two ways to accomplish the same goal: class Foo { public: static const size_t Life = 42; }; class Bar { public: enum {Life = 42}; }; Syntactically and semantically they appear to be identical from the client's point of view: size_t fooLife = Foo::Life; size_t barLife = Bar::Life; Is there any reason other than just pure style concerns why one would be preferable to another? 回答1: The enum hack used to be necessary because many

问题 This question already has answers here : In Java, are enum types inside a class static? (2 answers) Closed 3 years ago . I have an interface - here's a nicely contrived version as an example: public interface Particle { enum Charge { POSITIVE, NEGATIVE } Charge getCharge(); double getMass(); etc... } Is there any difference in how implementations of this would behave if I defined the Charge enum as static - i.e. does this have any effect: public interface Particle { static enum Charge {

问题 Closed . This question is opinion-based. It is not currently accepting answers. Want to improve this question? Update the question so it can be answered with facts and citations by editing this post. Closed 2 years ago . I'm working on a large project (for me) which will have many classes and will need to be extensible, but I'm not sure how to plan out my program and how the classes need to interact. I took an OOD course a few semesters back and learned a lot from it; like writing UML, and

问题 Sometimes it's necessary to prohibit a copy constructor in a C++ class so that class becomes "non-copyable". Of course, operator= should be prohibited at the same time. So far I've seen two ways to do that. Way 1 is to declare the method private and give it no implementation: class Class { //useful stuff, then private: Class( const Class& ); //not implemented anywhere void operator=( const Class& ); //not implemented anywhere }; Way 2 is to declare the method private and give it "empty"

问题 i have created this class for mesh loading it works but i added this new function to help speed up the loading. when i call the function my program breaks/stops. here is my function bool CXFileEntity::LoadXFile(const std::string &filename, int startAnimation, CXFileEntity *entity, LPDIRECT3DDEVICE9 d3ddev) { // We only support one entity so if it already exists delete it if (entity) { delete entity; entity=0; } // Create the entity entity=new CXFileEntity(d3ddev); if (Load(filename)) { delete

问题 I've been studying design patterns with a study group recently, and have come to understand that the builder pattern can be very useful for creating complex objects that are made up of many (potentially optional) parts. However, is there ever a point where the builder is doing too much? Let's say we have a class that has many many different combinations of objects, is there another pattern that may be better suited for that instead of making dozens of different builders? Is it possible to

问题 For context, I'm working on a C++ artificial-life system involving agents controlled by recurrent neural networks, but the details aren't important. I'm facing a need to keep two object hierarchies for the "brain" and "body" of my agents separate. I want a variety of different brain and body types that can be coupled to each other at run-time. I need to do this to avoid a combinatorial explosion caused by the multiplicative enumeration of the separate concerns of how a body works and how a