I have a question concerning good programming style. I have a group of methods that is handling the flow of my program. These functions uses objects from another class. Is it fine to make a class called something like Functions and list these functions I have there? Not a single instance would be created of this class. Should I rather not include these functions in a class at all? Basically they do stuff like opening the Main Menu and alike.
Not sure if this is a stupid question, I couldn't find any similar topics on this forum. I'm not asking how to do this, rather how to handle it regarding style.
Thanks a lot in advance.
This is exactly what namespaces are for. Don't try to wedge things into "the OOP way" when they don't fit. If your design says that you'll never create an object of a class type then it's not a class, just an agglomeration of functions.
While reading your question, I instantly thought about the Math class in Java (not sure what is the C++ equivalent). You probably know it, it is basically a collection of math operations. Math class
In my opinion, the kind of class you're talking about in your question must have a "collection of general functions" objective, similar to the Math class. Things like opening a menu should be a method of that menu or that menu's parent.
On the other hand, things like calculating some values using specific objects from your program or formatting elements following a customized pattern should be gathered in a "static" class in order to make that class an utilitary tool in your program.
Math operations are very general functions that can apply to any program. Try to transpose this concept within the context of your program! ;)
Put them in a class as static functions for now. You may realize later you'll have some commonality... perhaps state? Storing that in the class might make sense. And you'll want to check things there perhaps before calling your other objects... before you know it, you'll remove your static aspects and instantiate your own object. Perhaps even later consider multiple threads and several of these objects. You get the idea... leave yourself room for an object-oriented approach...
Related
I hate to beat a dead horse, that said, I've gone over so many conflicting articles over the past few days in regards to the use of the singleton pattern.
This question isn't be about which is the better choice in general, rather what makes sense for my use case.
The pet project I'm working on is a game. Some of the code that I'm currently working on, I'm leaning towards using a singleton pattern.
The use cases are as follows:
a globally accessible logger.
an OpenGL rendering manager.
file system access.
network access.
etc.
Now for clarification, more than a couple of the above require shared state between accesses. For instance, the logger is wrapping a logging library and requires a pointer to the output log, the network requires an established open connection, etc.
Now from what I can tell it's more suggested that singletons be avoided, so lets look at how we may do that. A lot of the articles simply say to create the instance at the top and pass it down as a parameter to anywhere that is needed. While I agree that this is technically doable, my question then becomes, how does one manage the potentially massive number of parameters? Well what comes to mind is wrapping the different instances in a sort of "context" object and passing that, then doing something like context->log("Hello World"). Now sure that isn't to bad, but what if you have a sort of framework like so:
game_loop(ctx)
->update_entities(ctx)
->on_preupdate(ctx)
->run_something(ctx)
->only use ctx->log() in some freak edge case in this function.
->on_update(ctx)
->whatever(ctx)
->ctx->networksend(stuff)
->update_physics(ctx)
->ctx->networksend(stuff)
//maybe ctx never uses log here.
You get the point... in some areas, some aspects of the "ctx" aren't ever used but you're still stuck passing it literally everywhere in case you may want to debug something down the line using logger, or maybe later in development, you actually want networking or whatever in that section of code.
I feel like the above example would much rather be suited to a globally accessible singleton, but I must admit, I'm coming from a C#/Java/JS background which may color my view. I want to adopt the mindset/best practices of a C++ programmer, yet like I said, I can't seem to find a straight answer. I also noticed that the articles that suggest just passing the "singleton" as a parameter only give very simplistic use cases that anyone would agree a parameter would be the better way to go.
In this game example, you probably wan't to access logging everywhere even if you don't plan on using it immediately. File system stuff may be all over but until you build out the project, it's really hard to say when/where it will be most useful.
So do I:
Stick with using singletons for these use cases regardless of how "evil/bad" people say it is.
Wrap everything in a context object, and pass it literally everywhere. (seems kinda gross IMO, but if that's the "more accepted/better" way of doing it, so be it.)
Something completely else. (Really lost as to what that might be.)
If option 1, from a performance standpoint, should I switch to using namespace functions, and hiding the "private" variables / functions in anonymous namespaces like most people do in C? (I'm guessing there will be a small boost in performance, but then I'll be stuck having to call an "init" and "destroy" method on a few of these rather than being able to just allow the constructor/destructor to do that for me, still might be worth while?)
Now I realize this may be a bit opinion based, but I'm hoping I can still get a relatively good answer when a more complicated/nested code base is in question.
Edit:
After much more deliberation I've decided to use the "Service Locator" pattern instead. To prevent a global/singleton of the Service Locator I'm making anything that may use the services inherit from a abstract base class that requires the Service Locator be passed when constructed.
I haven't implemented everything yet so I'm still unsure if I'll run into any problems with this approach, and would still love feedback on if this is a reasonable alternative to the singleton / global scope dilemma.
I had read that Service Locator is also somewhat of an anti-pattern, that said, many of the example I found implemented it with statics and/or as a singleton, perhaps using it as I've described removes the aspects that cause it to be an anti-pattern?
Whenever you think you want to use a Singleton, ask yourself the following question: Why is it that it must be ensured at all cost that there never exists more than one instance of this class at any point in time? Because the whole point of the Singleton pattern is to make sure that there can never be more than one instance of the Singleton. That's what the term "singleton" is all about: there only being one. That's why it's called the Singleton pattern. That's why the pattern calls for the constructor to be private. The point of the Singleton pattern is not and never was to give you a globally-accessible instance of something. The fact that there is a global access point to the sole instance is just a consequence of the Singleton pattern. It is not the objective the Singleton pattern is meant to achieve. If all you want is a globally accessible instance of something, then use a global variable. That's exactly what global variables are for…
The Singleton pattern is probably the one design pattern that's singularly more often misunderstood than not. Is it an intrinsic aspect of the very concept of a network connection that there can only ever be one network connection at a time, and the world would come to an end if that constraint was ever to be violated? If the answer is no, then there is no justification for a network connection to ever be modeled as a Singleton. But don't take my word for it, convince yourself by checking out page 127 of Design Patterns: Elements of Reusable Object-Oriented Software where the Singleton pattern was originally described…😉
Concerning your example: If you're ending up having to pass a massive number of parameters into some place then that first and foremost tells you one thing: there are too many responsibilities in that place. This fact is not changed by the use of Singletons. The use of Singletons simply obfuscates this fact because you're not forced to pass all stuff in through one door in the form of parameters but rather just access whatever you want directly all over the place. But you're still accessing these things. So the dependencies of your piece of code are the same. These dependencies are just not expressed explicitly anymore at some interface level but creep around in the mists. And you never know upfront what stuff a certain piece of code depends on until the moment your build breaks after trying to take away one thing that something else happened to depend upon. Note that this issue is not specific to the Singleton pattern. This is a concern with any kind of global entity in general…
So rather than ask the question of how to best pass a massive number of parameters, you should ask the question of why the hell does this one piece of code need access to that many things? For example, do you really need to explicitly pass the network connection to the game loop? Should the game loop not maybe just know the physics world object and that physics world object is at the moment of creation given some object that handles the network communication. And that object in turn is upon initialization told the network connection it is supposed to use? The log could just be a global variable (or is there really anything about the very idea of a log itself that prohibits there ever being more than one log?). Or maybe it would actually make sense for each thread to have its own log (could be a thread-local variable) so that you get a log from each thread in the order of the control flow that thread happened to take rather than some (at best) interleaved mess that would be the output from multiple threads for which you'd probably want to write some tool so that you'd at least have some hope of making sense of it at all…
Concerning performance, consider that, in a game, you'll typically have some parent objects that each manage collections of small child objects. Performance-critical stuff would generally be happening in places where something has to be done to all child objects in such a collection. The relative overhead of first getting to the parent object itself should generally be negligible…
PS: You might wanna have a look at the Entity Component System pattern…
When you have a set of functions that have no interaction between them, you place them in a namespace. (Example, a math namespace.)
When you have some public attributes and optionally a set of functions that act on those attributes, that should become a class.
But what about when you have a set of related functions but no public attributes? An example would be an event manager: you might only have subscribe(), post(), and dispatch() and no public attributes; however you do have hidden attributes like a list of subscribers and an event queue that the three functions act upon. Should this be a class or a namespace?
Any time you have behavior and state it should be a class, even if the state isn't publicly accessible. One practical reason for this is it makes it easier to unit test other modules that interact with the module in question.
A class. You have a state, albeit internal, so you may want to create two event managers (two queues).
This should definitely be class, because it has internal state. What if you need more than one instance? In that case namespace can't help you, and class can.
If you want to create one of more instances of the thing that each have a lifetime, then it should be a class.
An event manager sounds like something you want to create, use and then destroy. So, it should be a class.
namespaces were only really introduced to help with very large programs. In a large program you may have multiple teams of developers each writing code. It may not be feasible for each team to make sure that nobody else uses happens to give a function or class the same name as somebody else. Or, names of things may clash with 3rd party libraries that might want to be used. Namespaces help avoid these problems. If you're not working on a huge project, you probably don't really need to bother ever using namespaces for your own code, unless you feel the need to organize your code into a few namespaces just to keep it neat. Using unnecessarily small namespaces can make code painful to work with. There's not much point in over obsessing about whether code should be in this namespace or that one, it's better to focus on making sure the code actually works.
I often find myself in situations where objects need to communicate between each other. For example, a button might need to talk to various textboxes. Would it be proper to simply construct each widget with a pointer to the container for all of them? Would it be better to give it a pointer to a resource container map where the object can locate another object by string or something? This area has always been very vague to me. I could easily implement everything I want to do if I just constructed objects with pointers to containers of every other object, but that seems wrong. In the case of a widget, would it actually just be more proper if the widget knew nothing about the outside world and instead its action listeners were constructed with resource access?
Thanks
I understand that it is a bad idea but what are some solutions in these situations eg: good design patterns?
Any object should know as little as possible about things outside itself. What you are describing sounds alot like the ani-pattern often referred to as a 'God object'
You get better de-coupling if you use messages/events.
objects with pointers to containers of every other object, but that seems wrong.
And why do you think it is wrong?
Usually you will not just need to send messages but to do something like navigation/enumeration.
For example HTML DOM tree consists of nodes where each node contains [weak] reference to its parent. Without such reference operations like nextSibling() are just impossible.
So answer depends on set of other operations you will want to implement there.
The answer depends on how long the objects might live and how long the pointers might stick around. Anything which might change needs to go through a directory service. If the target's lifetime is short enough, you might even need to have the directory service place a hold on the target.
DON'T DO THAT!
No, seriously, your idea is analogous to the singleton pattern, with the difference that you have just one instance per "name" instead of per type.
You can collect a bunch of bad things about your idea by seeing what's wrong with singletons.
Why would a button in a dialog(?) want to know how many other objects there are in the dialog?
When the button is pressed, it sends a message to its owner. The owner will then have to coordinate the action between the widgets it owns. You don't want to change the code for you OK-button when the dialog gets another listbox, do you?
You could use dependency injection to pass the pointers you need. That way you make the dependencies explicit. http://en.wikipedia.org/wiki/Dependency_injection
This approach gives you a lot of advantages - unit testing is much easier when you don't have global state, god objects and so on. Also when new guy comes to the team, he can see what are the dependencies of a class - you make it explicit in constructor, so no magic like "you must first create this singleton to use that object or it will crash". This approach reduces coupling, thus making reuse easier.
IMO it is not possible to make every class independent of all the others (you ask if it is better when widget does not know anything about outside world). While this removes coupling making code reuse easier it also is very hard to do and leads to lot more coding.
On the other hand it is a bad idea to pursue some ideology "just because" without understanding why. Maybe in your case advantages of OOP are not worth writing additional code. If you can see that you will finish your application much quicker with "god object" then I would say "go for it".
IMO it is not as easy as "never create singletons and god objects". You must decide if additional time spent on passing all the references explicitly pays back in future.
Personally I always choose what is appropriate for program I write. It is not unusual for me to consciously break some OOP rules. Remember there are also other guidelines - I like KISS.
I am currently refactoring a very useful but poorly designed class in C++, and I'm running into a problem with the design: rather passing data around using arguments to methods, the data is passed around by setting private state variables in the class. This makes it very difficult for me to diagram out how data moves through functions. It's my weekend task to try and remove this style of passing data around as much as possible, as makes the program very impossible to understand from just the method signatures, as the signatures only tell a part of the story. I've decided
My current approach to test if a method communicates using private class-level variables is the following:
Edit the method and make it a function rather than a method, which removes its access to the state variables in the class.
Edit all of the calls to the method so that they call the function rather than the method.
Compile, see if anything breaks. Make a list of accessors to add to the original class.
Run the unit tests to see if I've broken anything in a very subtle way.
Is there a better way of doing this, perhaps one that can be easily automated? Is this refactoring a well-known technique that I can cite if I show it to other people?
The only mention of this problem that I've found so far is this quote from Coders at Work via the Object-oriented programming Wikipedia entry:
"The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." - Joe Armstrong
Edit in response to a good question from Oli Charlesworth:
I understand that the point of OOP is to sometimes communicate through state variables of the class. The difficulty with my current case is that there are currently 78 different data members in the class, many of which are key-value pairs of strings to other data types, and there are undocumented implicit dependencies on the order in which they need to be initialized. It's possible that given a sufficiently smart programmer working with this class would be easy, but it's currently very difficult for me. I think that several of these data types could be abstracted into their own classes, but before I can do that I need to understand more clearly how the data members interact with each other.
Given the clarification in the question my "are you sure it's not just that you don't like the other programmer's style" comment dies a death ;)
Personally I'd just refactor normally. That is, with 78 data members and lots of bits that are related but not in a class of their own I'd start by grouping the related data and extracting the functionality that works on it. There's no need, IMHO, to go through a stage where you explicitly pass the data into the functions in the existing class. Just pick a group of related data items, come up with a decent name, extract them and work out where they were used and how you need to move functionality into the new class.
Ideally, I'd start writing unit tests for the main class and the new broken out classes as I went along...
Instead of making all of the method's callers call the function, a smaller intermediate change would be to leave the method in place for all callers, and have it simply delegate by calling the function. Later you can inline the method call so all callers are directly calling the function.
Also, from your description it sounds like you are approaching this with manual testing. You will have better success (easier refactoring with reduced risk of error) with comprehensive unit tests in place, although of course the code you describe would be hard to unit test. Nevertheless, work toward more test automation.
Quick design question.
ClassA has a method called DoSomething(args)
In DoSomething(), before it can actually do something, it needs to do some preparatory work with args. I believe this should be encapsulated within ClassA, (as opposed to doing the prep work outside and passing it in) as nothing else needs to know that this prep work is required to DoSomething.
However, it's where the actual preparatory work code belongs that is making me think.
The preparatory work in my particular example is to create a list of items, which satisfy a certain condition, from args.
My hunch is that I should create a new class, ListOfStuff, which takes args in its constructor and put this preparatory work here.
From a TDD-perspective, I think this is the right choice. We can then unit test ListOfStuff til our heart is content. If we had put the preparatory work in a private method of ClassA, we'd have only been able to indirectly test it through testing DoSomething().
But is this overkill? Since adopting the TDD and DI approach, I've seen the number of classes that I write multiply - should I be worried?
Ta.
There are a couple of heuristics here.
Is there state on this class that
survives from invocation to
invocation? Does this prep work get
done every time you need to
doSomething(), or is it done and
saved? If so, that argues for the
class.
Does this computation need to happen
in more than once place? If so,
that argues for a class.
Can the details of the
implementation of the doSomething()
method, or the preparation work for
it, change without affecting the
enclosing class? If so, that argues
for a class.
Well, three heuristics. No one expects the Spanish Inquisition.
What is the simplest thing that could possibly work? That's the TDD mantra. Don't try to think too far ahead. If the time comes to create the helper class, you'll know it because you'll be doing all sorts of related work in multiple methods in other classes. Until then, do the work in your method. If it makes the method too long or cumbersome to read, extract the work to its own method. This method can also be tested to your heart's content without the need for another class.
Definately put it in a new class. Its called separation of concerns. You don't want to overload a class and make it do all sorts of other stuff. This is because your class will not be able to be used anywhere else as its so specific to one thing.
Put it in class, then use that class elsewhere. Otherwise you'd have to write this again and again in the future.
To make it extensible, and be able to pass in all sorts of different algorithms, the design pattern your after here is the Strategy pattern. But that is for the future...
Your object model design should be considered on it's own, rather than in the context of your development strategy. If building ListOFStuff and passing to to DoSomething really is how the object model fits together best, do it, regardless of your development strategy.
I think you've answered your own question a little, however, since ListOfStuff makes it easier to unit test, that probably means it's also a cleaner design.
Hope that helps!
Since adopting the TDD and DI
approach, I've seen the number of
classes that I write multiply - should
I be worried?
If your aim is procedural programming, yes. But since you're almost certainly wanting to work in an OO fashion, no.
Most people use too few types, spend too little time thinking about OO design.
Your questions about class responsibility reflect maturation of thinking (imho).
SoC is valid only if the "concern" in question has nothing to do with the class, or you find classes sharing this "concern" (aka, violating DRY). In your case, it seems that the code is intrinsic to the class - so possibly a private function would be more apt.
As tvanfosson said above, you need to balance SoC with YAGNI. Personally - I think you might be mulling over this prematurely (I know! I do it too all the time).