|
The fixed size array is a nono, this is where you should use some kind of a collection, probablye the List<Product> Matt already suggested.
But if you know beforehand you will need a Dictionary (not sure you do!) maybe you could stuff the fresh products in the dictionary right away?
PS: your Product class deserves to have a constructor that takes the basic values as parameters...
PS2: ... as well as a ToString() to return a formatted representation of itself.
|
|
|
|
|
Message Removed
modified 16-Mar-16 12:40pm.
|
|
|
|
|
I use:
private int _MyProperty
public int MyProperty
{
get { return _MyProperty; }
set { _MyProperty = value; }
}
private int myField;
public void MyMethod(int myField, int myProperty)
{
this.myField = myField;
_MyProperty = myProperty;
}In other words, I only use this when I need to pass the current instance to a method, or need to disambiguate two identical names. And anything starting with "_" is a backing field for a property.
This is (I believe) consistent with the recommended naming practices (which I can't find at the moment, damn it!)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: This is (I believe) consistent with the recommended naming practices
Hasn't been that way for a while I'm afraid. MS recommend against using the underscore[^].
This space for rent
|
|
|
|
|
That pretty much contemporary with the Net 1.1 version - if you look at the bottom it's copyright 2005!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
I do not know what a Valley Girl is, but it sounds from the context as though it is a derogatory statement implying a sexist viewpoint. Not appropriate for this site.
However, at the risk of being called a Valley Girl, I use this for all class member etc. I only use unadorned (i.e. not prefixed by scope + '.') for method local variables (ones that disappear when you exit the method / property) and global variables (NO! PLEASE DON'T USE GLOBAL VARIABLES! (unless you have inherited some code from the 1960s)). Anything associated with the class is prefixed by this, anything associated with another object is prefixed by the object variable name. This (no pun intended) ensures that everything is explicit. Never give future readers / maintainers the option of misunderstanding. OK, my source code may be a bit bigger with all of the this's but that is a small price to pay for clarity.
|
|
|
|
|
And if you refactor a field starting with "_" in VS it automatically removes the underscore:
private int _MyProperty;
public int MyProperty
{
get { return _MyProperty; }
set { _MyProperty = value; }
}
If you don't start with an underscore you get Yeuch!
private int MyProperty;
public int MyProperty1
{
get { return MyProperty; }
set { MyProperty = value; }
}
So I guess that MS's right hand isn't talking to it's left hand again... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
They are two different issues.
"This" can reference any field, property or method.
"_" is simply a prefix used to indicate (by past convention) that this is a "private field", regardless of whether it is a backing store or not.
It was a shorter version of the C/C++ convention which used "m_..." for its "members" (and which still finds its way into other languages).
"_" always implies "local to this instance" (and therefore "this" is assumed).
But that's just me 
|
|
|
|
|
|
Forgot to add that "_" also tells me it's not a "local variable" or "parameter", since they would otherwise all have the same name (using conventional camel-case rules).
|
|
|
|
|
MS doesn't follow their own naming conventions...
All my class members are PascalCase, all parameters/local variables are camelCase. So I don't need the this-keyword to initialize a class member from a constructor parameter and I don't use it anywhere else either. The leading underscore I only use if I happen to need an "explicit" backing field for a property.
I like it like this because: Looking at the first letter instantly tells you if it's a class member or a local identifier. No syntactically unneccessary visual this-clutter or underscore-clutter with the mentioned exception where it actually serves a purpose.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
|
N_tro_P wrote: That is what Griff said he does as well.
Not quite - Griff seems to use pascalCase for fields, requiring a this for initialization from parameters.
N_tro_P wrote: So what do we do here? Should they have an underscore?
I should have been more precise: I use the underscore only for a field if there is a property which returns that one field and possibly sets that one field (which introduces the problem of wanting to name the field like the property). So in your example I wouldn't use underscores because the properties return computed values, thus have a different meaning than any field and therefore will be named differently from any field.
N_tro_P wrote: where this fails is when extensions occur. A new requirement is added to a component that is a simple one. Expose someField with a public accessor. Now you must modify all usages of the field.
Yes, unless you can just change the field into a property. Lacking any sort of co-worker this hasn't been a problem for me
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
|
N_tro_P wrote: That is why we have auto-properties.
No, I didn't mean auto properties. I meant properties which, albeit reading and setting only one field, do a bit more than that, e.g. checking whether the new value is actually different to fire a PropertyChangedNotification only then.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
|
Auto-properties are not the same as a "private backed" property that just sets or returns the private field value. For example, an automatic property can't be used within the class as an out or ref call to a method. (And until fairly recently couldn't have a default value).
I really don't like exposing fields at all - it forces the design to remain unchanged - and you can't just "promote" a field to a property later because of the possible external use of the fields as out or ref parameters.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
(I moved this question from the .Net forum to make sure the reason for no replies isn't that it didn't get noticed.)
I'm looking for a light-weight, free-to-use Named-Lock-Manager solution in .Net.
Named-Lock-Manager in the sense that it allows to place locks on arbitrary objects represented by their name. There should be at least these lock-types: Null, Protected Read (Shared), Protected Write (Update), Exclusive.
Light-weight in the sense of being usable in-process and consisting of just some classes or a DLL (the license might require this distinction).
This is a new field for me, so my journey started with Google. I found this Wikipedia page Distributed lock manager[^] which, in principle, seems to describe closest what I'm looking for except that I don't need the distributed/networking stuff baked into it. But the existing solutions mentioned there (Apache Zookeeper, Redis, Google Chubby) don't fit my requirements of different lock-types and/or aren't light-weight (and Google Chubby presumably is proprietary on top of that).
I then somehow found LockManager Class (Microsoft.TeamFoundation.Framework.Server)[^] which seems to offer the functional features I'm looking for but (having zero knowledge about anything Microsoft.Team*) would probably require a TFS-Installation and a license for that?
I also found this, but it's too simplistic: https://dzone.com/articles/managing-business-object-locks[^]
And that's all I found so far (maybe I'm not using optimal search terms).
Do you know of an existing solution that fits my requirements or comes reasonably close?
Thanks,
Sascha
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Since you have never stated why you think you need a "lock manager", I do not think anyone is able to relate your "needs" (whatever they are) to an "existing solution".
|
|
|
|
|
Gerry Schmitz wrote: your "needs" (whatever they are)
I did specify my needs, at least as far as I think they are relevant.
Gerry Schmitz wrote: why you think you need a "lock manager",
For a pessimistic record locking scenario.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
You have "wants" ... they are not the same as needs within a particular application context.
If you expect more answers, you probably need to give a better explanation of the "problem" you are trying to solve.
|
|
|
|
|
Hmmm.. what I wrote in my original message aren't that my (assumed) needs?
I want to implement offline pessimistic locking on database records (by offline I mean without keeping a connection and transaction alive from reading to updating). And (I think) for that I need the outlined lock manager.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
The first rule of lock management is: DON'T use it (locks) (unless you have to).
The second rule of lock management is: DON'T use pessimistic locking (unless you have to); use optimistic locking.
I have yet to see where you "need" both, even though you "want" both.
A "transaction" is effectively a "lock"; which does not involve you worrying about locks.
|
|
|
|
|
Gerry Schmitz wrote: I have yet to see where you "need" both, even though you "want" both.
I didn't write I'd want both.
Gerry Schmitz wrote: A "transaction" is effectively a "lock"; which does not involve you worrying about locks.
I wrote that I don't want to keep a connection and transaction alive from reading to updating.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
