Quote:Original post by Squirm
We had one of those never ending "singletons are evil" discussions in #gamedev last night, in which I argued in favour of the use of a singleton for the logger class which handles debug output, warnings, errors, etc. I want one, I only want one, Having two would be detrimental to its purpose, I want it everywhere, and I want it everywhere for a good reason, not because of a poor design.

Your design is still poor. Only-one assumptions, implicit or explicit, are major dangers for writing robust code.

The bad design here is your logger. In general we want three things from logging: multiple logging sources (renderer, file manager, AI/logic), multiple logging sinks (file, console), and debug levels for how critical messages are. Classes will interact with a logger that has been assigned to them. Each logger object owns multiple sinks which may be configured differently, and multiple loggers can share sinks. This allows us to setup systems like so:
* The in game console gets renderer warnings and errors, but only errors from the internal managers. It does not get any messages from the AI/logic system.
* The debug file gets info messages, warnings, and errors from all sources.
This is a three logger system. One logger has been assigned to the renderer, which has two sinks attached: the console at warning level and the debug file at info level. One has been assigned to all of the internal managers with two sinks: the console at error level and the debug file at info level. One has been assigned to the AI/logic system with one sink: the debug file at info level. Note that none of the classes using the loggers know about the existence of either the console or the debug file.

You'll find that this level of flexibility is quite difficult to provide if all classes are sending their output to some kind of global object.

Quote:Original post by voguemaster

Quote:Original post by ApochPiQ
That mentality is that all operations should be done by objects, which is what most people mean by the term "object oriented." That mentality is unhealthy and leads down the Dark Path to languages like Java.

There is nothing wrong with Java. In many ways, Java is much better for development and debugging.

If you're talking about raw performance, as always that depends on the task at hand. Generalizing by saying that Java is slower than C++ is only technically true, not in reality.

When saying that Java takes away control from the programmer, that too is true but for 80% of the programmers, that's probably a good thing.

No dark path and no nothing. It all depends on your requirements.

That quote cannot be taken out of context without losing all of its significance.

Java's a great platform. The Java language is marginal. Java's obsession with objects is disgusting and causes code to be significantly more verbose than is really needed.

Writing "object oriented" code in any language tends to create designs that resemble Java programs, where every single piece of logic is contained in an "object" (i.e. class), even when that makes absolutely no sense. It is almost always possible to take an "OO" design, strip out objects where they are not strictly needed and write functional-style (or even procedural-style) code instead, and end up with a net improvement - code will tend to be more concise, more efficient, and better abstracted.

The typical "good OO design" is to build parallel vertical columns of abstraction, with small sets of objects working with each other and being "related" to a narrow hierarchy via inheritance. This model is fine in vacuum, but as soon as these objects have to start interacting, the typical solution is to build a lot of "helper objects" that take care of the interaction.

A far better way to build abstractions is in horizontal stratified layers. You basically build a mini-language; all logic should be expressed in high-level terms. Large projects may have several layers of such dialects. This produces code that is more reusable, more concise, easier to understand abstractly, and far more tolerant of small changes to specifications and requirements. (Watch the SICP video lectures for a good treatment of this.)


Using objects to model everything in a system leads to code that is needlessly verbose, buggy, prone to abstraction leakage, and intolerant of requirements changes. A classic symptom is the supposed "need" for things like Singletons and Monostates in the first place. The "canonical" Singleton, a logger, makes vanishingly little sense as an object the way most loggers are implemented. A namespace of functions would be far more appropriate.

Even Monostates are, in general, a poor attempt to disguise sets of functions as objects.


Some things just are not objects, and shouldn't be modelled as such. That's the point of my journal post, and the meaning of my reference to Java earlier.

Quote:
Some things just are not objects, and shouldn't be modelled as such. That's the point of my journal post, and the meaning of my reference to Java earlier.

I read the journal post, and while I agree with much of it in theory (to force everything into an object, even the application itself like Java and C# do, is ugly and inflexible), I think you may be taking it a bit far when it comes to denouncing object orientation.

Objects are a tool, but most of the time it is the best tool for the job. Anything that needs access to it's own data is immediately a conceptual object. Either you can create this object as a global (usually a global object, and only for the big stuff that spans the life of the application) or you can create it as a local object to some scope.

Of course, it is overkill to implement a collision library as a hierarchy of "Object->Sphere/Cube/Teapot->SquashedSphere..." because this creates needless complexity.

But a logging class could be a great object, consider it as a notebook... that's an object isn't it? It takes a log, stores all of the debug output, warnings, and such, and then can spit it out to a file or analyze it for anything you need to know. Sure, this could be done using a big global array of something or other, but it's better as an object.

Your logic is sound in theory, but it sounds like the only thing you think should be objects is something that you could hold in your hand. In reality, anything that is better represented as an object then not as an object (pretty much anything that needs it's own data) SHOULD be an object.

Object Aware. I like that. You just also need to be aware that they're damn useful most of the time. Just don't make your main() loop an object.