|
Pre version 2? Backward compatibility?
|
|
|
|
|
Which sounds plausable, but why allow the class to be instanced (by making it non-static) when it can never be instantiated (because the constructor is private)? Backwards compatibility is going to break anyway, just in a much more awkward spot.
|
|
|
|
|
Private, schmivate; I can call a private constructor or anything else -- which is why they introduced static classes in .net 2.
|
|
|
|
|
COM Interop?
COM requires a public constructor without parameters, and there it is.
And isn't it possible to access class methods through an instance with COM? When I remember those times when I was VB programmer correctly, that was possible, but I am not sure.
|
|
|
|
|
I think this is laziness on the part of MS. If (when?) the class definition changes in the Framework, the documentarians won't have to root around in the code to make sure that every method is still static.
|
|
|
|
|
I don't think your argument is valid. Static methods in non-static classes have their own uses. I have given one such (trivial) example.
Cheers,
Karthik
|
|
|
|
|
I agree: I use static methods in non-static classes all the time. But the question was about non-static classes with nothing BUT static methods.
|
|
|
|
|
Yes, I noticed that later. So I also updated my answer to take that in to account (see EDIT in my answer)...
Cheers,
Karthik
|
|
|
|
|
You could use static methods if the functionality of the method is not dependent on the instance properties/methods. Consider the following class as an example. There is a static "Parse" method that takes in a string and return a new instance of "Data". This static function "does not" depend on any of the instance properties/methods of the Data class. But it just creates an instance of the Data class for you to use. So, any other class that wishes to create an instance of Data (which has a ',' seperated int's) can do so by calling Data.Parse(_stringValue) .
public class Data
{
private List<int> a;
public Data()
{
a = new List<int>();
}
public Data(int[] nums)
{
a = new List<int>();
}
public static Data Parse(string nums)
{
string[] _nums = nums.Split(",".ToCharArray());
List<int> iList = new List<int>();
foreach(string s in nums)
iList.Add(int32.Parse(s));
return new Data(iList.ToArray());
}
}
PS - This is a just a trivial example of the usage of static methods in a non-static class.
Edit - If there are only static methods in a non-static, it might be useless, but it could also be for futuristic reasons. They could add to this class more instance properties / methods in the future that would use these static methods.
Cheers,
Karthik
|
|
|
|
|
Hello,
I am new to wpf. I am creating a application in which I wanted to change my image dynamically with some URL.
I am using code like
TheBinding is property which returns URL.
I tried lot other ways. But nothing is working.
Thanks in advance.
|
|
|
|
|
If you're binding to the image from something like a VM, you need to read the image in first. The easiest way to do this is to use something like this:
public BitmapImage TheImage
{
get
{
return LoadImageFromSource();
}
}
private BitmapImage LoadImageFromSource()
{
BitmapImage image = new BitmapImage();
try
{
image.BeginInit();
image.CacheOption = BitmapCacheOption.OnLoad;
image.CreateOptions = BitmapCreateOptions.IgnoreImageCache;
image.UriSource = new Uri( FullPath, UriKind.Absolute );
image.EndInit();
}
catch{
return DependencyProperty.UnsetValue;
}
return image;
}
|
|
|
|
|
BTW - you should have asked this in the WPF forum.
|
|
|
|
|
Here only Feb 11 discussion details only showing. Please resolve.
|
|
|
|
|
|
Top of the forum, on your right, there's a filter (on the bar with noise tolerance). Set the "Date Filter" to "All" and hit "Update"
I are Troll
|
|
|
|
|
Use the site bugs forum for any such issues.
This is the .Net framework forum.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
|
|
|
|
|
I've been programming with .NET for half a year now.
It's all pretty great and fairly easy, but I can't help to think that some classes/components were made to have an extra shell around them.
Take the whole process of connecting and reading/writing data from and to a database.
At the very least we need a Connection object and a Command object and dependent on what you want to do you need a DataReader, DataAdapter, Parameters, CommandBuilders, etc... It seems to me that constantly creating all those objects, configuring them etc. seems like a lot of work. So it would seem to me that it is easier to create a class that requires some parameters in its constructor, has some methods and functions that manage all the just mentioned classes and simply gives a resultset using something like DBClass.Execute.
Basically it would then look something like:
Dim myClass as New DBClass(aString, commandType, connectionString)
myClass.AddParam(name, DBType.Int, value)
Dim result = myClass.Execute ' Or myClass.ExecuteASync!
' Do stuff with the result.
Another example of stuff that just screams for an extra layer around it is the whole printing process.
Have the PrintDialog, PrintPreviewDialog, PageSetupDialog, PrintDocument, maybe PrinterSettings, the whole event thing...
I just want to say:
Dim p as New PrintClass(document)
p.Print ' Or, once again, p.PrintASync! ;)
At this point, is anyone really disagreeing with me?
Or do you really agree and know some other stuff that just calls to be put away in a programmer friendly class?
It's an OO world.
|
|
|
|
|
There are many Database access frameworks. Look at Microsoft Data Access Library, or Entity Framework, or nHiberate, and many others.
You may need, or think you need, a wrapper for the printer functions in your application, but other many not.
IMO, six months of experience is not enough for you fully understand the concepts of OOD and be able to make such generalizations.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I don't really think my six months of experience have anything to do with it... I know people who have been in the business for over twenty years and who really just don't get it. I'm also not saying I need a layer around the database access or printing because I don't understand what's happening, I'm saying I could use one because it saves a lot of work (and it's fun making them). Visual Studio's 'TableAdapter' and Entity Framework are good examples of that (in that aspect Microsoft already did the work for me ). Although there's probably many people out there that prefer their own database access layer above any other layer out there. Or people that wrap some exotic .NET functionality in a new easy to use class.
So I'm just asking what are you wrapping and why
It's an OO world.
|
|
|
|
|
Naerling wrote: I don't really think my six months of experience have anything to do with it
I think your statements highlight your youthful inexperience quite well. Please, continue.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I think that if six months of experience is the only thing you read in my question that says more about you than me...
Just give me the answer you would have given me if I had not mentioned my 'level of experience'.
It's an OO world.
|
|
|
|
|
Naerling wrote: So I'm just asking what are you wrapping and why
Database layers - always.
Communication layers - always
Specification layers - always (where a specification might differ from a communication layer in that say a service provider might provider a description of IP interactions to get an XML result. First is communication, second is dealing with a data.)
I always have disparate code for the following as well although whether it is a 'layer' or library is not as clear.
- Logging
- Different types of business logic
- Security utilities
- Unit testing (to emphasize that the unit testing code is contained separately.)
- Executable wrappers (server, command line, etc whatever makes it into a specific executable is kept separate from rest of business logic.)
Goal of doing this is to make unit testing easier and to make maintenance, in terms of the layer, easier. This should occur because making it in to a layer should reduce coupling thust changes are less likely to ripple.
Naerling wrote: Or people that wrap some exotic .NET functionality in a new easy to use class.
Or even day to day functionality but which is implemented in a completely weird way, such as the email client code.
|
|
|
|
|
Naerling wrote: I can't help to think that some classes/components were made to have an extra shell around them.
Most of use have an assembly (or multiple) that contain utility-routines. Great for building prototypes, where you can generalize away and focus on the functionality.
Naerling wrote: It seems to me that constantly creating all those objects, configuring them etc. seems like a lot of work. So it would seem to me that it is easier to create a class that requires some parameters in its constructor, has some methods and functions that manage all the just mentioned classes and simply gives a resultset using something like DBClass.Execute.
That's a lot of assumptions on how the code is going to be used. I'm launching a few IDbCommand s on a single IDbConnection (or two), sometimes in transaction, sometimes in a separate thread.
Naerling wrote: At this point, is anyone really disagreeing with me?
Or do you really agree and know some other stuff that just calls to be put away in a programmer friendly class? Smile
Lots of extension-methods from the Tips & Tricks section, like the StringBuilder-extensions[^]
I are Troll
|
|
|
|
|
Thanks for the tip on extensions, I'll look up some more. I'm not quite familiar with extensions yet, so that should be interesting
I think that when you're creating a shell around some classes, like in the case of DB access, you often lose some flexibility or even functionality (depends on what you want with it and how much time and effort you put into creating your shell). But the big pro to doing this is that it saves time and effort later on.
And the question remains if it is even a con that you lose functionality if you weren't using the functionality in the first place. Let's say your company ONLY uses the command object to execute stored procedures (some weird company policy), even for simple select statements, would it really be that bad if you would build a class that does not support the CommandType.TableDirect or Text anymore? Perhaps your company would even encourage it, so people are not even tempted to break the SP's only policy
It's an OO world.
|
|
|
|
|
Naerling wrote: And the question remains if it is even a con that you lose functionality if you weren't using the functionality in the first place.
You only loose functionality if you demand that "only" those routines are allowed to do database-access. I don't see any value whatsoever in such a restriction.
Naerling wrote: Let's say your company ONLY uses the command object to execute stored procedures (some weird company policy)
I'd be looking for a position in a different company - I wouldn't want to work at a carpenters shop where they only use 2-inch nails either, always becomes a mess
Naerling wrote: would it really be that bad if you would build a class that does not support the CommandType.TableDirect or Text anymore?
Yes, simply because you're obviously not familiar with the consequences. There's always a use-case that doesn't fit the "neat" scenario, otherwise you'd bu simply using Microsoft Access (it offers most functionality most db-applications tend to generalize)
What happens when I need to load a lot from the database? You could write routines for all cases, but then you'd prolly end up with more than a "few" routines. That's where objects win over procedural programming; we can recombine with it all as required, and I could replace the database with a plain textfile by providing my own IDbConnection .
I are Troll
|
|
|
|