I'm trying to understand how the line:
private Queue<IProductable> inventory { get; set; }
It is used in the entire code below. I'm only used to seeing properties defined using simple types; so, this really confused me. Also, I'm curious why the constructor for the class Factory (below) uses:
inventory = new Queue<IProductable>();
Instead of:
Queue<IProductable> inventory = new Queue<IProductable>();
My understanding is when you instantiate an new object, you should do: CLASS/TYPE newObjectName = new CLASS/TYPE. Is the constructor even instantiating a new "inventory" object? If so, why don't I have to specify what type the object "inventory" is (in order to use it to invoke methods from the generic Collections class, Queue).
Anyway, below, is the code. I'm hoping someone can explain this in the easiest possible way for me to comprehend/remember when I need to do something similar in the future.
namespace codeExample
{
class Factory
{
private Queue<IProductable> inventory { get; set; }
public Factory()
{
inventory = new Queue<IProductable>();
}
public IProductable GetOldestItem()
{
IProductable oldestItem = inventory.First();
return oldestItem;
}
public IProductable GetNewestItem()
{
IProductable newestItem = inventory.Last();
return newestItem;
}
public void Add(IProductable productToAdd)
{
inventory.Enqueue(productToAdd);
}
}
}
My understanding is when you instantiate an new object, you should do: CLASS/TYPE newObjectName = new CLASS/TYPE. Is the constructor even instantiating a new "inventory" object?
If the type were included then it would be creating a new local variable. Currently the code is not creating a new variable, it is using the property instead, which is a part of that class's instance data (at least in this case). The property (in this specific context) acts almost exactly like a private field would. It is creating a variable that exists for the lifetime of the whole object, not just one method.
Is the constructor even instantiating a new "inventory" object?
It's creating a new queue object, yes. The property definition defines where a queue may be stored, but it doesn't create an actual queue. The constructor actually creates a queue (which is empty) and assigns is to the variable.
The private Queue<IProductable> inventory { get; set; } declares an auto-implemented property, but it could as well have been a field:
private Queue<IProductable> inventory;
This declares a private instance variable, which you can access from any method in this class, but not from derived classes or from outside the class.
Your code assigns a value in the constructor, which is always run before other code in the class:
inventory = new Queue<IProductable>();
So now from everywhere in this class you can access inventory.
I'm only used to seeing properties defined with simple types; so, this
really confused me
Why? You can define properties of any type.
Also, I'm curious why the constructor for the class Factory (below)
uses:
You can't define the type of the property again, it's already available in the current scope because it's a class property. Its type is defined at the line private Queue<IProductable> inventory { get; set; }
My understanding is when you instantiate an new object, you should do:
CLASS/TYPE newObjectName = new CLASS/TYPE
No, here is a simple counter-example in two lines:
MyType myVariable;
...
myVariable = new MyType();
private Queue<IProductable> inventory { get; set; }
is an auto property.
it's equivalent to
private Queue<IProductable> _inventory;
public Queue<IProductable> Inventory
{
get { return _inventory; }
set { _inventory = value; }
}
Thus, you just declared a member inventory, and later on you instantiate a Queue<IProductable> and store its reference to the auto property inventory.
inventory = new Queue<IProductable>();
private Queue<IProductable> inventory { get; set; } is an automatic property. The implementation of get/set are provided by the compiler.
vs
Queue<IProductable> inventory = new Queue<IProductable>();
Now, inventory is a field. Properties have backing stores and are smarter than fields. They allow a programmer to do work during get/set operations.
Is the constructor even instantiating a new "inventory" object?
Yes, in the example the constructor is setting the hidden variable (backing store).
If so, why don't I have to specify what type the object "inventory" is
(in order to use it to invoke methods from the generic Collections
class, Queue).
Because you are not declaring a new variable in the constructor. We are setting a property.
Here you could use a field instead of a property. However, I would expect an "advanced class"/Factory to use Dependency Injection and thus a public property would make sense in such a case. (Maybe you simplified the original code?)
Related
So I am working on a F# project, and need to access some C# classes. In particular, one of the C# class looks like this:
class LoginRequest {
public string Scope {get; private set;}
}
Now with C# itself, an instance can be created easily with object initializer: new LoginRequest() {Scope = "all"} for example.
However, I could not figure out a way to create such an instance from F#. Any tips?
For the given example there is no easy (non-reflection, see below) way, i.e. private setters are inaccessible from C# and F#:
new LoginRequest { Scope = "s" }; // CS0272 The property or indexer 'LoginRequest.Scope' cannot be used in this context because the set accessor is inaccessible
LoginRequest(Scope = "s") // error FS0495: The object constructor 'LoginRequest' has no argument or settable return property 'Scope'.
For accessing the private setter, you could use
let r = LoginRequest()
typeof<LoginRequest>.GetProperty("Scope").GetSetMethod(true).Invoke(r, [| "scope" |])
r.Scope // scope
However, I would strongly discourage the use of reflection. The most obvious reason being that you lose compile time safety.
What's the difference between:
public List<MyType> Something{ get; set; } = new List<MyType>();
and
public List<MyType> Something{
get{
return new List<MyType>();
}
//set...
}
Context:
I'm unsure of the behaviour I'm seeing in my code. A service is there on constructor, but null on a future method call in the what I assume is the same instance of the class.
The first line:
public List<MyType> Something{ get; set; } = new List<MyType>();
will be called once when the object (that has this property) is instantiated. It is a one time creation of an instance of Something.
The second example is an explicit implementation of the getter. Every time you access the getter of Something it will return a new and empty list.
EDIT:
The first line is called an auto-property initializer for a detailed answer have a look at a post by Jon Skeet. This feature exists since C# 6.0
I thought the new C# 6.0 property initializers like this.
public MyType MyProperty { get; } = new MyType(OtherProperty);
was the equivalent of this
private MyType _myVariable;
public MyType MyProperty { get { return _myVariable ?? _myVariable = new MyType(OtherProperty); } }
(that OtherProperty is available as part of the instance, not limited to being static)
But in the above first I get "field initializers cannot reference non-static field". Am I doing it wrong, or are property initializers just as limited as
public readonly MyType MyVariable = new MyType(NeedsStaticReference);
In your second example the field is set on first use.
The problem here, is the field intializer is set immediately before the constructor, and there is no guarantee the other property is set or constructed or what order this happens.
If you want to assign something on construction you will need to do it in the constructor
Fields (C# Programming Guide)
Fields are initialized immediately before the constructor for the
object instance is called. If the constructor assigns the value of a
field, it will overwrite any value given during field declaration.
A field initializer cannot refer to other instance fields.
And some more information
A field can optionally be declared static. This makes the field
available to callers at any time, even if no instance of the class
exists. For more information, see Static Classes and Static Class
Members.
A field can be declared readonly. A read-only field can only be
assigned a value during initialization or in a constructor. A
static``readonly field is very similar to a constant, except that the
C# compiler does not have access to the value of a static read-only
field at compile time, only at run tim
It's, actually, like this:
private readonly MyType _myVariable = new MyType(OtherProperty);
public MyType MyProperty { get { return _myVariable; } }
Thus, the issue.
I have 2 variables
Date-Time-Modified which is a Date-Time variables
Is-Deleted variable which is a boolean.
These two variables are found in each class I have and I need to have these variables initialized each time I insert, edit or delete an object from my database. Is there a way to do this?
Use a base class. Add the 2 needed properties (DateTime, IsDeleted). Every derived class now holds this properties. You can set them individually or iterate over the base type to assign a value.
You can also use events to trigger the update automatically. But i think you just want to create an entry and then set its DateTime property to the actual date time.
You also could delegate this task to the database. It will take care of setting this attributes.
An example for my lazy friend ;)
abstract class DatabaseEntryBase
{
public DatabaseEntryBase()
{
// You can initialize properties to a default value here
this.IsDeleted = false;
}
public DateTime ModifiedTime { get; set; }
public bool IsDeleted { get; set; }
}
class Entry : DatabaseEntryBase
{}
static void Main()
{
//-- Do your SQL stuff --//
var newEntry = new Entry();
newEntry.ModifiedTime = DateTime.Now;
newEntry.IsDeleted = false;
}
If you need all instances to hold the same values (e.g. multiple deletes) push them into a collection (here EntryCollection of type List<DatabaseEntryBase>) and iterate over them instead:
public void SetAllItems()
{
foreach (DatabaseEntryBase entry in EntryCollection)
{
entry.ModifiedTime = DateTime.Now;
entry.IsDeleted = [...];
}
}
Using an interface will accomplish the same! It could be named ITaggable and defines this two properties as a contract.
Have a base class that has these members and then have the other classes extend that one.
Then have a method on the base that initalises them. Then call that method on the inserts and such.
base.InitialiseVariables()
Is there any other way to just initialize them without the need of
calling a method?
Probably another approach for this is Aspect-Oriented Programming. For example, PostSharp.
Code will look something like this:
[UpdateTimestamp]
public void InsertProduct(Product product)
{
// Your logic here
}
Consider the class:
public class foo
{
public object newObject
{
get
{
return new object();
}
}
}
According to MSDN:
Properties are members that provide a flexible mechanism to read,
write, or compute the values of private fields. Properties can be used
as though they are public data members, but they are actually special
methods called accessors. This enables data to be accessed easily
And:
Properties enable a class to expose a public way of getting and
setting values, while hiding implementation or verification code.
A get property accessor is used to return the property value, and a
set accessor is used to assign a new value. These accessors can have
different access levels. For more information, see Accessor
Accessibility.
The value keyword is used to define the value being assigned by the
set indexer.
Properties that do not implement a set method are read only.
while still providing the safety and flexibility of methods.
Does this therefore mean that at some point in time the value of the newObject property has a reference to the returned new object?
edit removed readonly from property
edit2 also would like to clarify that this is not the best use for a property but its done to try and illustrate the question more effectively.
You return a new object on each access to the property and that is not the expected behavior of properties. Instead you should return the same value each time (e.g. a value stored in a field). A property getter is simply glorified syntax for a method that returns a value. Your code compiles into something like this (the compiler creates a getter by prefixing the property name with get_ which is then emitted as IL):
public class foo
{
public object get_newObject()
{
return new object();
}
}
Each call to the getter will create a new object that foo doesn't know about or has access to.
Does this therefore mean that at some point in time the value of the newObject property has a reference to the returned new object?
No.
Property using a backing field:
class Foo {
readonly Object bar = new Object();
public Object Bar { get { return this.bar; } }
}
Using automatic properties:
class Foo {
public Foo() {
Bar = new Object();
}
public Object Bar { get; private set; }
}
A property is accessed using the same easy syntax as a public field. However, by using a property you can add code to the getter and the setter allowing you to do stuff like lazy loading in the getter or validation in the setter (and much more).
Under the hood, your property will simply be calling a function named get_newObject() that looks like this:
public object get_newObject()
{
return new object();
}
Since that is the case, it will always return a new object every time it is invoked.
If you want to retain a reference to the object, then I would recommend creating a private field to hold the data and having the property access that field, like so:
private object myObject;
public object newObject
{
if(myObject == null)
{
myObject = new object();
}
return myObject;
}
Since your property doesn't define set, and your field is private, newObject is basically eradonly outside of the containing class.
Properties in C# are "syntactic sugar". The code within the get block of a property is in fact put into a hidden get_PropertyName() method, and the set block into a hidden set_PropertyName() method. In the case of your code, the following method will be created:
public object get_newObject()
{
return new object();
}
You can see these hidden methods if you view the compiled assembly using Reflector, or ildasm.
When the property is used, the C# compiler converts any "get" accesses of your property into calls of the get_newObject() method. As an example:
If you were to write the following:
var foo = new foo();
var aNewObject = foo.newObject;
The compiler would convert that to:
var foo = new foo();
var aNewObject = foo.get_newObject();
So, in answer to your other question, the newly created object returned when someone "gets" the property won't be stored within your foo instance, the caller will simply get a new object every time.
Not exactly. Properties are just syntactic sugar so that you don't have to write accessor methods (like Java).
So this:
private int _myInteger;
public int MyInteger
{
get { return _myInteger; }
set { _myInteger = value; }
}
is equivilant to this:
private int _myInteger;
public int GetMyInteger()
{
return _myInteger;
}
public void SetMyInteger(int value)
{
_myInteger = value;
}
and it gets better with this, which is also equivilant:
public int MyInteger { get; set; }