It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
In one of our projects I found this code
class A
{
private B b = new B();
protected void AMethod()
{
var x = b.DomeSome();
}
}
My question, is this a "clean" way of coding? Would it be cleaner to instantiate b in AMethod?
Does is depend?
If you create an instance of b in AMethod, then the variable will lost after AMethod ends. So each call of AMethod will create a new object B.
On the other hand, having the variable declared at class level (like in your example) will allow you to reuse the instance of B for all the calls of AMethod.
There is not precise answer on how is cleaner unless your provide us with more context
If DomeSome changes the state of B the logic would be different if B was instantiated on every call of AMethod.
With this amount of code given: The code is clean and it depends.
Would it be cleaner to instance b in AMethod?
It would be different. In the current code b is instantiated when A is instantiated.
Does ist depend?
Yes
Yes It totally depends upon you requirement.. That b variable of type B may be needed somewhere else too so it has been declared in the Class.
And there is no hard defined specifications on clean coding. Keep coding as long as its concise, understandable and does what it needs to do.
Also I assume you have changed variable names to A & B for posting here.. if these are present in actual code.. CHANGE IT NOW !!
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I've done a bit of research on this and it seems pretty impossible but none of the answers have been specific enough to my issue. I currently have a Stack<object> that I push objects of multiple different types to. Before I push them I box them to object so it accepts them. Is there any possible way of automatically unboxing the object to the original unboxed type?
You can use the extension method OfType<OneOfTheTypes>() to get only those objects of that specific types casted to the correct type.
You can not automatically convert an object to a variable with the compile time type of a compatible type of the runtime type the object has.
The type of a variable is a compile time type and if the content is not known by the compiler to be of that type at compile time. The compiler does not know what runtime type each object in your stack actually has. You have to make a promise to the compiler (with a cast) that the runtime type will actually match the compile time type.
But to be frank. This kind of "check what type I have" is a typical smell of a bad design. Try to design your code with a common base class if you have similar types of objects or use different kinds of storage for different kind of objects.
There is no Automagic way to do it.
try this though
var objT = (T)Convert.ChangeType(obj, typeof(T));
var tuple = new Tuple<object, Type>(someObject, typeof(someObject));
stack.Push(tuple);
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Java and C# return type of methods are by reference or value? It's really confusing for me, need some explanation.
Thank you all.
In Java everything is returned by value. That includes references and here's where the confusion is!
If I have:
Trade t = new Trade();
then t is a reference (we'd say it is-a Trade, but that refers to the type. t really is a reference). When I return that from a method, I'm returning the reference, by value. The reference still points to that original object.
Hence if I return that t from a method and then invoke a further method on it, it invokes the method on the Trade that it originally pointed to.
C# can return results by either value or reference - it depends how you define the method.
Java can only ever return by value (or strictly speaking, return reference by value.)
As this little Memory Slogan goes in HeadFirst Book..
Roses are Red,
This poem is Choppy,
Passing By Value is
Passing By Copy.
In Java its always Value that is passed or returned.
Where as in C# it can return either by Reference or by Copy.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
i have a list with: Circle, Triangle, Rectangle in it
i want to edit the element with the id X but list[X].radius; is not available because it is a child class.
You will have to detect the dynamic type of the element at runtime.
IShape value = list[x];
if(value is Circle)
{
((Circle)value).radius = 5;
}
You can also do something like:
Circle value = list[x] as Circle;
if(value != null)
{
value.radius = 5;
}
This has the advantage of being a bit faster, since the cast is only done once.
When you have a mixed list and want to access members defined for the derived types, you have to cast to the derived type.
((Circle)list[index]).Radius = 10; // alternately use is or as if you're unsure
Of course, by the virtue of simply having a mixed list, you're saying that you generally do not care about the differences between the derived types, you're content with using the base polymorphically. If you find yourself in a different position, you should perhaps rethink your strategy for storing or consuming these elements.
Typecast it:
((Circle)list[X]).Radius
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
How would you name an interface which provides 1 method inUse()?
I would actually reconsider the name 'inUse()' in the first place; A boolean value obviously has only two possible values, but you're actually adding the ability to get a state. I'd consider declaring an enum
public enum UsageState
{
Idle,
InUse
}
and name your interface IHasUsageState. This gives you the flexibility of adding things like Starting, Finishing, WaitingToBeUsed or other options depending on precisely what is is you're doing, for example if you have threading issues to deal with in the future.
Also, you eliminate the need for negative checks like if (!obj.InUse()) { } in favor of the more readable and intuitive if (obj.Usage == UsageState.Idle) { }, not to mention you may decide in the future that you might want it to specify WHY it's idle.
IUsageIndicator if you want to show that your object is currently in use or not.
IUsable if you want to show that your object can be used or not.
I would name it. IInUse. Looks good...
I would prefer to name it as IUsable keeping in mind the standard conventions that MS follows. (Eg: IEnumerable, IComparable etc)
I would prefer
InUsable. Sounds everlasting.
see here
I would name it. IUsable. Looks good...
This is what I would have done in Java
public interface Usable {
public boolean inUse();
}
It should start with Uppercase 'I', so the interface name becomes in your case IInUse.
Follow the C# coding standards over here.
How about IExclusiveUseObject?
are you looking for answers for both c# and java?
As a c-sharper, I prefix with "I" and most c# developers I talk to do also, probably because it's in the microsoft naming conventions.
However interestingly when search around for java naming conventions I see a mix of prefixed and no prefix.
So in c# perhaps something like:
public interface IUsable {
void InUse();
}
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I'm just asking this, because the same happened to me when trying to iterate over a DataRowCollection:
DataSet s;
...
foreach (var x in s.Tables[0].Rows)
{
//IntelliSense doesn't work here. It takes 'x' as an object.
}
I saw #Marc Gravell answer in Why is there no Intellisense with 'var' variables in 'foreach' statements in C#?, and now it's clear to me why this is happening.
I decided to take a look at the code of the DataRowCollection class, and GetEnumerator() is:
return this.list.GetEnumerator();
where list is a DataRowTree type that inherits the abstract class RBTree<K> (by the way, never knew there was an implementation of a Red-Black Tree in .NET before) which implements IEnumerable instead of IEnumerable<K>.
Is too hard to make RBTree<K> implement IEnumerable<K>? That would solve the main problem here.
I suppose it was developed like this in previous versions of .NET, but that doesn't really make sense anymore, does it?
My question is:
Is .NET old code updated in new releases? (for example, make DataRowCollection implement IEnumerable<DataRow> instead of IEnumerable)
Breaking changes, such as changing the class hierachy, is only implemented if there's a really good reason. In this case it's only for convinience.
An example of why it's a breaking change:
Let's say a project has these two methods.
public void Foo(object obj){
Console.WriteLine(obj.ToString();
}
public void Foo<T>(IEnumerable<T> obj){
throw new Exception();
}
now the change you want will make a program that has been recompiled but not changed throw an exception every time instead of printing to the console. It's not that it throws that's the problem but that the behaviour is different.
There's other ways such a change could break/alter a perfectly good program so the benefits (being able to write var in foreach loops) does not outweigh the cost (designing, implementing,testing,documenting), nor the potential costs of breaking customers work.