class-design

问题 Possible duplicate: why-is-java-lang-throwable-a-class Hi! I doesn't understand why Throwable isn't abstract class. I see only one use case for these: in logging systems for figure out call hierarchy. But it can be some static method for this or other class. So, why?) Thanks. upd from java.util.logging.LogRecord // Get the stack trace. StackTraceElement stack[] = (new Throwable()).getStackTrace(); Why it can't be Throwable.getStackTrace(); or as in java.lang.Thread (new Exception())

问题 Im trying to come up with a solution where the class that processes a "message" is selected at runtime depending on the message type. I know that i can use something like this if msg_type = "A" MsgAProcessor.execute(message); else if msg_type = "B" MsgBProcessoror = execute(message); .... .... .... I dont want to use the above approach as i dont want the code to know anything about the message types that i could be processing. I want to be able to in the future add a new message processor for

问题 The case: I have a form class which handles HTML forms, cleans up fields and validates. I'm thinking about creating separate classes for the different form fields, e.g.: text / file / select / etc. The way I'm considering to use this is something like the following: $form = new Form(); $form->element['fieldname'] = new HtmlTextField('length'=>3); However someone here on SO told me once that a class construct should never return anything. In the above case it would return the form field. Is it

问题 Imagine I have a class used to represent some trivial numerical data, like a vector. I want this class to be immutable in terms of its members, but still support correct copy-assignment behaviour. This is what the shell of this class might look like: class Vector { public: Vector(float _x, float _y); private: const float x; const float y; }; I would like to be able to assign a new value to a vector member within (for example) a class. An on-screen entity with a position, perhaps, represented

问题 I'm working on a custom user control. How can I prevent the HEIGHT ONLY of the control from being modified during the design-time interface. 回答1: You can override the SetBoundsCore method and disallow changes to height by changing the height value before calling the base class implementation. private const int FixedHeightIWantToKeep = 100; protected override void SetBoundsCore( int x, int y, int width, int height, BoundsSpecified specified) { // Fixes height at 100 (or whatever fixed height

问题 I'm trying to write a class which contains several std::vectors as data members, and provides a subset of vector's interface to access them: class Mesh { public: private: std::vector<Vector3> positions; std::vector<Vector3> normals; // Several other members along the same lines }; The main thing you can do with a mesh is add positions, normals and other stuff to it. In order to allow an STL-like way of accessing a Mesh (add from arrays, other containers, etc.), I'm toying with the idea of

问题 In Python, I'm trying to extend the builtin 'int' type. In doing so I want to pass in some keywoard arguments to the constructor, so I do this: class C(int): def __init__(self, val, **kwargs): super(C, self).__init__(val) # Do something with kwargs here... However while calling C(3) works fine, C(3, a=4) gives: 'a' is an invalid keyword argument for this function` and C.__mro__ returns the expected: (<class '__main__.C'>, <type 'int'>, <type 'object'>) But it seems that Python is trying to

问题 I have the following class CppProperty class that holds value: template<typename TT> class CppProperty { TT val; public: CppProperty(void) { } CppProperty(TT aval) : val(aval) { } CppProperty(const CppProperty & rhs) { this->val = rhs.val; } virtual ~CppProperty(void) { } TT operator=(TT aval) { this->val = aval; return this->val; } friend TT operator++(CppProperty & rhs); friend TT operator--(CppProperty & rhs); friend TT operator++(CppProperty & rhs, int); friend TT operator--(CppProperty &

问题 I have the following class CppProperty class that holds value: template<typename TT> class CppProperty { TT val; public: CppProperty(void) { } CppProperty(TT aval) : val(aval) { } CppProperty(const CppProperty & rhs) { this->val = rhs.val; } virtual ~CppProperty(void) { } TT operator=(TT aval) { this->val = aval; return this->val; } friend TT operator++(CppProperty & rhs); friend TT operator--(CppProperty & rhs); friend TT operator++(CppProperty & rhs, int); friend TT operator--(CppProperty &

问题 While filling in The Object Oriented Concepts Survey (To provide some academic researchers with real-life data on software design), I came upon this question: What is the limit N of maximum methods you allow in your classes? The survey then goes on asking if you refactor your classes once you reach this limit N. I've honestly never thought about such a limit while designing my applications and wonder what the reasoning behind this is. Why would I want to self-impose myself an arbitrary number