I am a ColdFusion developer but I assume that my question will apply to many different languages.
I currently have control, service and DAO layers within my model structure.
I have a specific environmental variable called DSN (data source) which is used a lot throughout my application. (There may be more of these variables in the future.)
I began by storing this value in the application scope. However our application functionality has changed since inception and the DSN can now change during a user's login.
In addition I am planning to build test harnesses for my system which would allow testing my system over different scenarios in which this variable would change.
So the variable has become mutable.
One option would have been to set the variable on my DAO objects' instantiation.
But I also implement Wirebox dependency management and for performance reasons would like as much of my model as possible to be singletons so this is not an option.
My final solution (which will require a lot of re-factoring) is to pass the DSN through from all of the layers—so a default DSN value can be overridden on any method call (each method will have a DSN argument which defaults to the application value).
Obviously I would like to avoid this additional work, but I cannot think of any other way around it. Hope explanation is sufficiently clear and any help would be greatly appreciated.
Related
In Unity you have to tell the engine which are the parameters to serialize.
Not only that, some of them are not serializable (like dictionaries, for instance), and you need to specify it very clearly and carefully.
I'm really confused to find nearly no documentation in any book or official page about it. Not even questions in the forums. Seems like a blueprint thing only... and not really it.
What I need to know if the state of the editor variables state are stored in the scene when you save it (serialized) and also when you enter Play Mode.
How about creating instances of a component whose UPROPERTIES values are also set in the editor but created using Macros from other files. Those are quite dynamic. Are those stored too?
(I understand that the constructor is executed everytime you open the scene. I'm only interested in this case... not creating the instance via code, since you can set those values hardcoded)
I'm running tests, but would help some information about all this. Maybe Unreal stores every single thing and that's why there's no info about it...
As far as I know about UE serialization, variables marked with UPROPERTY macro are subjects to a CDO mechanism (or at least those marked as EditDefaultsOnly, EditAnywhere and similar Attributes that lets you edit it's value in editor). CDO is Class Default Object and basically it holds initial data for UObjects.
Values of those properties could be set in C++ or editor and later changed (overridden) on actual instances or defaults of derived classes (meaning Blueprint classes as well). If you don't want to store value of a property, you can use Transient flag (c++) or checkbox (BP). I often use it for cached items which I find during gameplay.
Note, that in C++ constructor, those properties are not correctly initialized. And they are not correctly initialized until PostInitProperties() is called, which is after CDO initialization.
I found usefull reading about Actor's lifecycle UE Docs and it helped me a lot.
I've had a certain feeling these last couple of days that dependency-injection should really be called "I can't make up my mind"-pattern. I know this might sound silly, but really it's about the reasoning behind why I should use Dependency Injection (DI). Often it is said that I should use DI, to achieve a higher level of loose-coupling, and I get that part. But really... how often do I change my database, once my choice has fallen on MS SQL or MySQL .. Very rarely right?
Does anyone have some very compelling reasons why DI is the way to go?
Two words, unit testing.
One of the most compelling reasons for DI is to allow easier unit testing without having to hit a database and worry about setting up 'test' data.
DI is very useful for decoupling your system. If all you're using it for is to decouple the database implementation from the rest of your application, then either your application is pretty simple or you need to do a lot more analysis on the problem domain and discover what components within your problem domain are the most likely to change and the components within your system that have a large amount of coupling.
DI is most useful when you're aiming for code reuse, versatility and robustness to changes in your problem domain.
How relevant it is to your project depends upon the expected lifespan of your code. Depending on the type of work you're doing zero reuse from one project to the next for the majority of code you're writing might actually be quite acceptable.
An example for use the use of DI is in creating an application that can be deployed for several clients using DI to inject customisations for the client, which could also be described as the GOF Strategy pattern. Many of the GOF patterns can be facilitated with the use of a DI framework.
DI is more relevant to Enterprise application development in which you have a large amount of code, complicated business requirements and an expectation (or hope) that the system will be maintained for many years or decades.
Even if you don't change the structure of your program during development phases you will find out you need to access several subsystems from different parts of your program. With DI each of your classes just needs to ask for services and you're free of having to provide all the wiring manually.
This really helps me on concentrating on the interaction of things in the software design and not on "who needs to carry what around because someone else needs it later".
Additionally it also just saves a LOT of work writing boilerplate code. Do I need a singleton? I just configure a class to be one. Can I test with such a "singleton"? Yes, I still can (since I just CONFIGURED it to exist only once, but the test can instantiate an alternative implementation).
But, by the way before I was using DI I didn't really understand its worth, but trying it was a real eye-opener to me: My designs are a lot more object-oriented as they have been before.
By the way, with the current application I DON'T unit-test (bad, bad me) but I STILL couldn't live with DI anymore. It is so much easier moving things around and keeping classes small and simple.
While I semi-agree with you with the DB example, one of the large things that I found helpful to use DI is to help me test the layer I build on top of the database.
Here's an example...
You have your database.
You have your code that accesses the database and returns objects
You have business domain objects that take the previous item's objects and do some logic with them.
If you merge the data access with your business domain logic, your domain objects can become difficult to test. DI allows you to inject your own data access objects into your domain so that you don't depend on the database for testing or possibly demonstrations (ran a demo where some data was pulled in from xml instead of a database).
Abstracting 3rd party components and frameworks like this would also help you.
Aside from the testing example, there's a few places where DI can be used through a Design by Contract approach. You may find it appropriate to create a processing engine of sorts that calls methods of the objects you're injecting into it. While it may not truly "process it" it runs the methods that have different implementation in each object you provide.
I saw an example of this where the every business domain object had a "Save" function that the was called after it was injected into the processor. The processor modified the component with configuration information and Save handled the object's primary state. In essence, DI supplemented the polymorphic method implementation of the objects that conformed to the Interface.
Dependency Injection gives you the ability to test specific units of code in isolation.
Say I have a class Foo for example that takes an instance of a class Bar in its constructor. One of the methods on Foo might check that a Property value of Bar is one which allows some other processing of Bar to take place.
public class Foo
{
private Bar _bar;
public Foo(Bar bar)
{
_bar = bar;
}
public bool IsPropertyOfBarValid()
{
return _bar.SomeProperty == PropertyEnum.ValidProperty;
}
}
Now let's say that Bar is instantiated and it's Properties are set to data from some datasource in it's constructor. How might I go about testing the IsPropertyOfBarValid() method of Foo (ignoring the fact that this is an incredibly simple example)? Well, Foo is dependent on the instance of Bar passed in to the constructor, which in turn is dependent on the data from the datasource that it's properties are set to. What we would like to do is have some way of isolating Foo from the resources it depends upon so that we can test it in isolation
This is where Dependency Injection comes in. What we want is to have some way of faking an instance of Bar passed to Foo such that we can control the properties set on this fake Bar and achieve what we set out to do, test that the implementation of IsPropertyOfBarValid() does what we expect it to do, i.e. return true when Bar.SomeProperty == PropertyEnum.ValidProperty and false for any other value.
There are two types of fake object, Mocks and Stubs. Stubs provide input for the application under test so that the test can be performed on something else. Mocks on the other hand provide input to the test to decide on pass\fail.
Martin Fowler has a great article on the difference between Mocks and Stubs
I think that DI is worth using when you have many services/components whose implementations must be selected at runtime based on external configuration. (Note that such configuration can take the form of an XML file or a combination of code annotations and separate classes; choose what is more convenient.)
Otherwise, I would simply use a ServiceLocator, which is much "lighter" and easier to understand than a whole DI framework.
For unit testing, I prefer to use a mocking API that can mock objects on demand, instead of requiring them to be "injected" into the tested unit from a test. For Java, one such library is my own, JMockit.
Aside from loose coupling, testing of any type is achieved with much greater ease thanks to DI. You can put replace an existing dependency of a class under test with a mock, a dummy or even another version. If a class is created with its dependencies directly instantiated it can often be difficult or even impossible to "stub" them out if required.
I just understood tonight.
For me, dependancy injection is a method for instantiate objects which require a lot of parameters to work in a specific context.
When should you use dependancy injection?
You can use dependancy injection if you instanciate in a static way an object. For example, if you use a class which can convert objects into XML file or JSON file and if you need only the XML file. You will have to instanciate the object and configure a lot of thing if you don't use dependancy injection.
When should you not use depandancy injection?
If an object is instanciated with request parameters (after a submission form), you should not use depandancy injection because the object is not instanciated in a static way.
I have spent the last couple of hours reading about the singleton pattern and why not to use it, amongst others those really good sites:
Singleton I love you, but you're bringing me down
How to Think About the "new" Operator with Respect to Unit Testing
Where have all the Singletons Gone?
I guess quite a lot of you know these already.
Looking at my code after reading that, I clearly am one of the maybe 95% of programmers that misunderstood and misused the singleton pattern.
For some cases, I can clearly remove the pattern, but there are cases where I am unsure what to do:
I know singletons for logging are accepted, one reason for that being that information only flows into them but not back into the application (just into the log file or console etc of course).
What about other classes which do not meet that criteria but are required by a lot of classes?
For example, I have a settings object which is required by a lot of classes. By a lot, I mean more than 200.
I have read into some other SO questions like "Singletons: good design or a crutch?", and all of them pointed out why using singletons is discouraged.
I understand the reasons for that, but I still have one major question:
How do I design a class which needs a single instance, accessible from everywhere, if not using the Singleton pattern?
The options I can think of would be:
Use a static class instead (though I don't see how this would be any better, looking at OOP and unit testing).
Have it created in an ApplicationFactory and perform dependency injection on every single class that needs it (keep in mind it's 200+ for some cases).
Use a singleton anyway, as the global access bonus outweighs the disadvantages for that case.
Something completely different.
It will depend on exactly what you mean by a settings object.
Do all 200 classes need all the settings; if not why do they have access to the unused settings?
Where do the settings come from and is there a good reason why each class can't load its settings as and when required?
Most importantly though, don't make changes to working code just because the code uses a pattern which is frowned upon. I've only used the singleton pattern once but I'd use it again.
EDIT:
I don't know your constraints but I wouldn't worry about multiple access from a file until it had been shown to be an issue. I would split up the configuration into different files for different classes/ groups of classes or, preferably, use a DB instead of files with different tables providing data for each class.
As an aside I've noticed that once you put the data in a db people seem to stop worrying about accessing it multiple times even though you're still going to the file system in the end.
PS: If other options aren't suitable I'd use a singleton... you want data to be globally available, you're not willing to use dependency injection, you only want the file to be read once; you've limited your options and a singleton isn't that bad.
Isn't this already discussed extensively and exhaustingly?
There is no misuse of the pattern. If your software works as expected (inlcuding maintainability and testablility) you are right with singletons.
The thing about people complain is that the singleton pattern has more impact than only restrict a class to have a single instance.
you introduce a global variable
you cannot build a subclass
you cannot reset the instance
If all this is not a problem for you: Use singletons all over the place. The pattern discussion is academic and hairsplitting.
And - to answer your question - checkout the monostate vs singleton thread: Monostate vs. Singleton
I'm undecided as to what classes I could have that could adapt to an existing system which is an online video game. Here's what I want to achieve:
Get a series of settings from objects in the server.
Listen for clients to connect.
For each client, check that the settings on the client correspond with those from the server.
If settings don't correspond (something has been tampered with), either disconnect the client or change their settings.
This will be handled by class that will act as an entry point and can serve as a form of controller.
Now, the settings are strewn accross a number of instances: players, weapons, flags, lights, etc. In procedural programming, I'd get all this information and store it an array. However, is there a better way of doing this according to an OO approach? Can I make one or more classes that will have the values of these settings and act as a form of facade?
Encapsulate the settings data and behavior into at least one object (i.e. Settings). Depending on how your system is constructed this becomes part of other objects' composition (e.g. Player, Weapon, etc...), perhaps via dependency injection, or referenced from some global context. Settings is responsible for validation the match between client and server (e.g. Settings.validateClientServerSettingsMatch()). In terms of retrieving individual settings, two possible approaches explicit or implicit.
Explicit
Your Settings object, or perhaps other entities that make its composition, have methods for each setting managed. So it could be something like Settings.getPlayerSettings().getSomeSetting() or 'Settings.getSomePlayerSetting()`. How nested really depends on your system. Either has the advantage of making clear what settings are available to the client development and it procides compile time type checking if you're using a language such as Java. The tradeoff is needing to alter an object every time a new setting comes into play.
Implicit
This just has a generic method in the Settings object - Settings.getSetting(settingName). This makes it very easy to add settings, at the expense of any sort of useful type checking, unless you do something on your own using some meta magic of sorts in a language such as Python or Ruby or large case statements in Java.
I've inherited a project that stores various parameters either in a config file, the registry and a database. Whoever needs one of these parameters just reads (and in some cases writes) it directly from the store. This, or course, is stupid, so my first thought was to refactor the existing code so that the client doesn't know where the parameter is stored in. I created a classic AppSettings class that has a property for each parameter. Since the store has to have global scope I made a thread-safe singleton. The class doesn't store the parameter values in fields but rather acts as an access point by reading and writing them to and from the actual store, be it config file, registry or database. These days it's hard to avoid all the talk about the dangers of singletons and global state. I will take a proper look at dependency injection and Spring etc later, but for now, I just have a couple of questions.
What type of problems, other than testability, can you see with my solution?
What would be a light weight alternative? Creating a factory for each object that uses the parameters is not an option (too much work).
Wouldn't using a singleton serve as an acceptable compromise until I have a chance to do some heavier refactoring?
If the properties in my singleton class only had getters, would that make it OK?
I can anticipate that the store for some of the parameters will change in the future (eg. from registry to database), so that was my motivation for hiding the store behind a singleton class.
This is a bit of a non-answer, but I highly recommend the c2wiki's pages on Singletons as a reference http://c2.com/cgi/wiki?search=Singleton
And also the page http://c2.com/cgi/wiki?GlobalVariablesAreBad
I think the general verdict is that global state creates coupling between vastly different parts of your system that must be thought about and designed around very carefully. The question is, are all of those settings truly global and needed by disparate parts of the system? If not, then is there any way to separate them into smaller parts that can live inside different modules at a lower access level?
If it's a small project I wouldn't worry too much about it, but there is a lot of wisdom on those c2wiki pages about global state and singletons being a pain for larger projects.
I would challenge the assumption that since the config data is global, that you need a global singleton to access it, especially for reading. Consider creating an AppSettings class that can be invoked as needed to read your config settings.
If you need to write in a thread-safe manner, you can create a static (or singleton) private member of the AppSettings class to control writing only. Thus any instance of AppSettings can write, but the "global" access is actually restricted to the AppSettings class.
Thanks, guys. I would consider this a medium-size project (about 200KLOC) and it's C#. The problem is that the project has a long and troubled history and a lot coders have worked on it. As much as I'd like to properly learn dependency injection (as I do understand and subscribe to the concept), the deadline is closing fast so now is not the time for it. After looking at my current singleton class I decided to split it into two instance classes. Some of the parameters are used all over but some only in a single assembly. And like Doug said, I can achieve thread-safety just as easily with an instance class.
As for the various dependency injection frameworks, the problem is there are too many. I've briefly looked at Spring and Unity. I wish I could find a summary of the differences.
Thanks again!