Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am developing a software in WPF c#. My software has multiple windows. I need to share a same instance of on object across multiple windows (I am using legacy code, so I can not make that object static). Is it a good practice to have a static class which will have variables that I need to share across multiple windows, so I can avoid passing them through a constructor. Thank you
You could either use a static class or you could inject all windows/view models with the same singleton instance. Note that this doesn't necessarily has to be a class that actually implements the singleton design pattern but you need to make sure that you inject the windows/view models with the very same instance.
The latter approach is the preferred one, mainly because a non-static shared class can implement an interface which enables you to easily replace the implementation with another one which in turn makes it a lot easier to unit test your classes.
So it is not, at least in the general case, really a good practice to use a global static class but this might still work in your specific scenario.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm building a C# WPF app that will use IBM iSeries data for starters but will use oracle data via web service later. In order to switch between them (and support testing) we create interfaces and program the view to interface, right? Each of the data sources would be responsible for mapping to a common DTO structure used in the view model.
So if these two data sources that implement the interfaces are in separate projects, where are the interfaces defined? I'm thinking about how to define the interfaces so I don't have to keep up separate versions in the respective data source projects. If I create the interfaces in the view then it would create circular reference, the data source needing the view for the interfaces and the view needing the data source for dependency injection.
Please forgive me for the rather generic question. I'm not asking "how do I structure my app", it's more of how do I solve the specific issue of the mechanics of the interfaces.
Thanks, Mike
Put them in a separate project. Add a reference to that project wherever you want to use them.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Ok, this subject is probably done to death but I wanted to throw it out there to see what people thought of my approach.
I need to create a simple WinForms application that will consist of a handle of forms. There will be variables that I can stick into the app.config as they'll never really change. However there will be some variables that are pulled in from a database unique to the user thats logging in. It's these variables that I need to persist and make available to the rest of the application to drive appropriate business logic.
Based on other articles on StackOverflow my plan would be to use the singleton pattern with IoC. So first instantiating a class based on the singleton pattern which is hooked up to an interface. The instantiated object would then be passed into the constructer of other methods in program.cs where I'll arrange most of my objects. This should mean I can easily test and mock this and other classes (I think?).
I've seen there are two ways of creating a class based on the singleton pattern, one that is the 'classic' way of doing it but isn't thread safe. The other requires slightly more coding but would be thread safe. My WinForms project would be pretty simplistic and wouldn't require multiple operations running in the background. Just simple CRUD operations fired off from the UI. For ease, I thought I'd use the classic singleton (non-thread safe) approach. That said, is that a bad thing to do, even for the most simplest of WinForm apps?
If you're using .NET 4.0+, just use Lazy<T> class for your singletons. If you insist on not caring about thread safety (why though?), get => _value ?? (_value = GetValue()) is enough.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I've read Clean Code by R.C. Martin and I'm trying to adopt his suggestions about clean code as broadly as possible.
But I'm not sure how to name related classes.
Let's say I have a class named TreeDirectoryList.
I want to cut implementation of this class into many smaller classes.
Let's say I'll create a class named ParentIndexStack.
ParentIndexStack will implement functionality very dependent on TreeDirectoryList, so it's very not probable that this implementation of ParentIndexStack will be useful with any other class in the future.
But the name of ParentIndexStack is very generic, it's possible, that I'll need another class with the same name, within the same project.
So I thought I'll name ParentIndexStack more precise, like TDLParentIndexStack (prefix TDL is from TreeDirectoryList).
Would it be correct ?
I'll end with many classes starting with TDLxxxxx.
One option is to put that set of classes in their own namespace. Then you can have simple, concise names that still communicate the full meaning of the class through the namespace context.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
A "God Namespace" is the (uncommon) term for an (anti?)pattern analogous to the "God Object", when you stuff a metric ton of stuff (mostly methods/functions) that is not related or not closely related to each other into one huge namespace/static class just so that it can be used in multiple sections of your project.
When following that (anti?)pattern, you often end up, as a C# example, with something like a static class Assets with tons of methods mostly unrelated to each other, but used across multiple places in your project(s).
I usually approach this problem by letting the next Assets grow for as much as I can bear it, and then desperately try to sort its contents out into several smaller ones based on the criteria which seems most legit, like MathAssets, or BitmapAssets, or RNGAssets, and then end up forgetting what did I put where... and make a new Assets for several new methods which don't fit into either of the SomethingAssets already cluttering up the project.
Are there any other ways of clearing up the "God Namespace"? Or will I just have to live with good old static class Assets?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The project I work on has multiple layers and each layer's object is being used in the subsequent layer. But some of the classes do not have any interfaces and have non virtual methods. So basically I will not be able to use a mock framework to stud those classes from other layers. When I asked the developer to create an interface for the same class, so that I can mock it, he asked me why should I create an interface if I am not going to reuse it.
Is it a good practice to write interface just to improve the testability of the code?
Your code should be loosely coupled and has good dependency management to allow you write unit-tests easily. If you can't write unit-tests easily, it's the first sign that your code is not well-architectured enough, and you need to refactor it. So, your motivation to change production code(in your case to add Interface) should be to make your code better, not just to aid testing. If you could do the first - you would get the second for free.
Btw, one of the main benefits of following the TDD practice is that the good architecture is enforced from the beginning: it's difficult to write untestable code, because you write tests before you write code.
So, the answer is YES, it's OK to add Interface, but it should be done for the sake of good architecture, not just to help you write tests for bad architecture.