Jump to content
  • Advertisement

David Neubelt

Member
  • Content Count

    269
  • Joined

  • Last visited

Community Reputation

866 Good

About David Neubelt

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. David Neubelt

    Why You Shouldn't Be Making an MMO

    Here is another point of view from another guy that made a real MMORPG. [url="http://duatiu.blogspot.com/2011/05/duatiu-faq.html"]http://duatiu.blogspot.com/2011/05/duatiu-faq.html[/url] -= Dave
  2. David Neubelt

    Principles of Software Engineering

    Quote:Original post by Emmanuel Deloget Second question: why should this single instance be global? the only reason I see is that you need to access this instance from everywhere in the code - that's typically a good sign of a common design flow - a locality problem. I don't know anything which have to be global and used by all the services of an application. Or, to be more exact, I know only one thing: system resources. And global system resources are best used using functions, because the system is supposed to know about their state internally. If these functions need some id (representing an instance of something) to work, then this is not a global resource, since providing two different id will have a different result. So this cannot be represented by a singleton, as the id might change. If there is no intrinsic data to store, then why using an object? A function is going to do the job just as correctly. I'd like to quickly address your second question. Quote:Second question: why should this single instance be global? I am not going to argue that allowing a variable to be global across an application is bad design. I also believe it is bad design. I'm arguing that you can have global variables that are exposed to one module and only one module. In this sense, it is local to that module but global across all files in that module. There are two points we can argue here a) the effectiveness of a global variable and b) the single instance of an object. I'm sure we can both agree the advantage of a global variable in a library. Let's focus on the single instance of an object. Problem domain for single instances of objects If you are writing a module that needs to handle a system resource then I disagree on your view that a function call will always be the best idea. Imagine that the system resource gives you ownership of volatile variables. Having multiple access to these variables can cause system crashes and to protect your design you limit the entry point to those variables. This type of hardware implies the code has to control the state of the hardware. In this type of system there can only be one variable that controls the hardware and you must model your design with this restriction to protect against system crashes. You say that all systems should know their state internally by function calls but this just simply isn't true. I'm currently working on hardware that forces you to create a variable for the OS to use (they have it externed) and then make changes to that variable! There isn't always a fancy OS to hide all the details for you and for certain consoles there is a close one-to-one mapping of hardware state and variable state. I suggest for this domain of problems: * Wrap the volatile state of the OS in a class. * Only allow a single instance (single entry point). * Allow every file in the library access to that class. -= Dave
  3. David Neubelt

    Principles of Software Engineering

    Quote:Original post by Promit Here it is. A first round of Promit's Principles of Software Engineering. I may expand on this list in future posts, but this will get us started nicely. 1) There are no legitimate uses of the singleton design pattern. I disagree. I believe that in most situations you may have encountered that the implementation of a singleton on a class has been a bad design. I do not feel that the pattern in itself has no legitimate use. I'm only talking about the unique instance of the pattern and not the other properties. I'd like to draw a comparison, give reasoning and finally provide an example. First, I believe the pattern can be applied on objects as a modifier, much like the constant modifier. The implementation should not force the object to have all classes always have one instance but rather it should modify the class. For this program, my design says that having more then one instance of the class would be erroneous so let me mark it as having only one instance. Anything more would result in an error. It is a protection scheme much like statically typed languages. For another program, it would be acceptable for this class to have multiple instances so I would not mark it as a single instance. In an ideal language it would look like this class MyClass; // <-- declared MyClass = single // <-- in an implementation file somewhere else In C++ I've created a similiar construct that isn't as ideal. CGlobal<MyClass> inst1; CGlobal<MyClass> inst2; // second instance is the same as the first Notice, that in another program I could decide to use a second instance by not using CGlobal and another class. This allows me to decide on a per project basis or even per library basis of whether it makes sense to mark the class as having one instance. The point I'm getting at is that in certain domains having more than one instance is erroneous and any constructs we can use to enforce the design will be a step in the correct direction and lead to less buggy code. By allowing a choice of having multiple instances or single instance the design pattern creeps between the line of a singleton and multiton. Which gives it a more flexibility then it was originally designed. It makes sense that any class that encapsulates physical interaction with devices on a system that you will want to have one copy of that class. Imagine that this class will be managing interactions with physical devices that only allow control of a volitle variable through one thread. Anymore attempts to access that variable will cause a system failure. Also, imagine that this certain instance of this class needs to be seen by one module. By design: * This module needs only one instance of the class any more will result in a hardware failure. * The class needs global view from every other file in that module. Solution: * Protect the hardware by enforcing a singleton design on the class. It can manage state of the device and prevent any attempts to misuse it. * Perhaps, on another console you can have multiple access to the device so do not enforce that the class always has to be a singleton. This should be a modifier for that particular class in that module. -= Dave
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!