Maybe I should just make this a public member, but I keep thinking it should be a constant.
SCENARIO
I have forms I'm rendering into PDFs (using iTextSharp). In code, the forms themselves all inherit a base class (OrderForm). Within OrderForm, there are a list of constants that I use for measurements when aligning things for the PDF rendering, such as LEFT_MARGIN, etc. These constants are used in several functions to determine where things go.
All the forms are virtually identical as they are comprised of the same components (header, address boxes, items, etc). However, the layout of the forms differ slightly... on one form, the address box is an inch further to the right (to fit in the envelope window my employer uses).
ISSUE
Rather than create a slew of constants for each margin, padding, blah blah for each form in the base class, eg: PURCHASE_ORDER_LEFT_MARGIN, INVOICE_LEFT_MARGIN, etc, wouldn't it be better to create an overridable LEFT_MARGIN that can be set in the "inheritee" [sic] object? My reasoning is that it is a constant that will not change within that object, only form to form, yet the renderings in the base class will remain relative to whatever that constant is.
I know I could simply create a public member and set its value, but I'd like to know the right way to go about this.
Thanks.
Constants are implicitly static (Shared).
Use a Readonly Property instead, and then you can choose to override it whenever or wherever need be.
A quick example ....
Class BaseClass
' Assume this field is set with a value from somewhere else'
Private _leftmargin As Integer
Overridable Readonly Property LEFT_MARGIN As Integer
Get
Return _leftmargin
End Get
End Property
End Class
Class DerivedClass1
Inherits BaseClass
Overrides Readonly Property LEFT_MARGIN As Integer
Get
Return 5 'specialized case for this class'
End Get
End Property
End Class
Class DerivedClass2
Inherits BaseClass
'uses base class LEFT_MARGIN'
End Class
Constants are compiled as literal values. If you have this (C#) source code:
public static class MyStringTestClass
{
// Fields
public const string ConstString = "Const String";
public void TestMethod()
{
string sc = MyStringTestClass.ConstString;
SomeOtherFunction(sc);
}
}
then the compiler will produce this:
public static class MyStringTestClass
{
// I'm not 100% sure if this declaration is removed as well...
public const string ConstString = "Const String";
public void TestMethod()
{
// ...but I know for sure that it will be removed
// everywhere it's used - including other assemblies!
string sc = "Const String";
SomeOtherFunction(sc);
}
}
As you see, "ConstString" is completely GONE and it's literal value is inserted everywhere.
So use the VB.net equivalent of a ReadOnly Virtual Property (I think "virtual" is called "Overridable" in VB.net?) and override it.
What you want is a regular property ... Any value that changes is not a constant ... :)
What you can do is to use methods instead of constants. At the base class the method will return the value of the constant as it is now.
Inheriting class can provide a new value for the "constant" by overriding the corresponding method.
Related
I have a VB class. It's big, so I'm posting a simplified example here:
Public Class ExampleClass
Public Property Foo As String
Public Property Bar As String
End Class
Suppose I have a text file like this:
foo,123
bar,456
And I want to read the file and populate the properties of my object accordingly.
Simplest way I can think of is to add a method with a case statement, like this:
Public Class ExampleClass
Public Property Foo As String
Public Property Bar As String
Public Sub SetProperty(prop As String, val As String)
Select Case prop
Case "Foo"
Foo = val
Case "Bar"
Bar = val
End Select
End Sub
End Class
But as my class will have around a hundred properties, so my SetProperty procedure is going to get big and boring to put together, and probably not be the most maintainable. Is there a better way to do this?
Before you tell me, I shouldn't structure my data this way, I know. However, this is a legacy database table that I have to live with. I'm updating the application with some new Entity Framework and LINQ code that will allow me to drop some very ugly stored procedures.
Thanks for your help.
James
You can find each object property via reflection
MyClass myClass = new MyClass();
System.Reflection.PropertyInfo pi = myClass.GetType().GetProperty("Foo");
if (pi != null && pi.CanWrite)
{
//Check the type before assignment...
if (pi.PropertyType.IsAssignableFrom(typeof(string)))
pi.SetValue(myClass, value, null);
}
I am very confused with properties in asp.net.
I just don't understand why we use properties and when I should use them. Could anybody elaborate a little on this.
public class Customer
{
private int m_id = -1;
public int ID
{
set
{
m_id = value;
}
}
private string m_name = string.Empty;
public string Name
{
set
{
m_name = value;
}
}
public void DisplayCustomerData()
{
Console.WriteLine("ID: {0}, Name: {1}", m_id, m_name);
}
}
Properties provide the opportunity to protect a field in a class by reading and writing to it through the property. In other languages, this is often accomplished by programs implementing specialized getter and setter methods. C# properties enable this type of protection while also letting you access the property just like it was a field.
Another benefit of properties over fields is that you can change their internal implementation over time. With a public field, the underlying data type must always be the same because calling code depends on the field being the same. However, with a property, you can change the implementation. For example, if a customer has an ID that is originally stored as an int, you might have a requirements change that made you perform a validation to ensure that calling code could never set the ID to a negative value. If it was a field, you would never be able to do this, but a property allows you to make such a change without breaking code. Now, lets see how to use properties.
Taken From CSharp-Station
There are a couple of good reasons for it. The first is that you might need to add validation logic in your setter, or actually calculate the value in the getter.
Another reason is something to do with the IL code generated. If you are working on a large project that is spread over multiple assemblies then you can change the code behind your property without the application that uses your assembly having to recompile. This is because the "access point" of the property stays the same while allowing the implementation code behind it to be altered. I first read about this when I was looking into the point of automatic properties as I didnt see the point between those and a normal public variable.
It's easy.
All fields in class MUST be private (or protected). To show fields to another class yyou can use properties or get/set methods. Properties a shorter.
P.S. Don't declare write-only properties. It is worst practices.
Properties are a convenient way to encapsulate your classes' data.
Quoting from MSDN:
A property is a member that provides a flexible mechanism to read,
write, or compute the value of a private field. Properties can be used
as if they are public data members, but they are actually special
methods called accessors. This enables data to be accessed easily and
still helps promote the safety and flexibility of methods.
Let's consider two common scenarios:
1) You want to expose the Name property without making it changeable from outside the class:
private string m_name = string.Empty;
public string Name
{
get
{
return m_name;
}
}
2) You want to perform some checks, or run some code every time the data is accessed or set:
private string m_name = string.Empty;
public string Name
{
get
{
return m_name;
}
set
{
m_name = (String.IsNullOrEmpty(value)) ? "DefaultName" : value;
}
}
see:
http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx
The most important reason is for validation purpose in setter and manipulation part can be implemented in get part.
For Ex.
Storing weekdays, which should be from 1-7, if we take normal variable and declare it as public, anyone can assign any value.
But in Properties setter you can control and validate.
The next one you can use it for tracking. That means, you can know how many times set and get functions has been called by clients (statistical purpose, may be not useful frequently).
Finally, you can control read only, write only and read/write for the properties according to your requirements.
I need to bind request parameters to an instance of the following Java class (getters and setters omitted):
public class ShippingHouse {
private String name;
private String description;
private List<ShippingRule> shippingRules = new ArrayList<ShippingRule>();
}
public class ShippingRule {
private ShippingHouse shippingHouse;
private String name
}
Notice that there is a 1:N relationship between ShippingHouse and ShippingRule, but each ShippingRule also has a reference to the ShippingHouse thaat owns it.
If these were Grails command/domain classes, I would bind them with request parameters
name=foo&description=bar&shippingRules[0].name=sr0&shippingRules[1].name=sr1
But it doesn't seem like this will set the reference to the owning ShippingHouse within each ShippingRule. Is there a way I can bind this automatically, or must I write the code myself?
Don,
You will need to write code to do it yourself using BindUsing or some other approach. The binder doesn't (and shouldn't) assume anything about back references from a parent to a child. If these were GORM entities and the relationship was explicit, that is different, but in your case the binder should not assume that shippingHouse property in the ShippingRule class has anything to do with the shippingRules property in the ShippingHouse class.
Also note that lucke84 said that your "private" is implicit. Make sure you understand what that means if you are going to remove them. If you remove them the compiler is going to generate public getter and setter methods for those properties, which may or may not be what you want.
If you want to implement a 1:N relationship between the two classes, you should use the right grails approach. Something like this:
class ShippingHouse {
String name
String description
static hasMany = [shippingRules: ShippingRule]
}
class ShippingRule {
String name
static belongsTo = [shippingHouse: ShippingHouse]
}
Please note that semicolons are useless and the "private" declaration on class fields is implicit.
I have two classes in two separate libraries (one VB, one C#):
Public Class Item
...
Public Overridable ReadOnly Property TotalPrice() As String
Get
Return FormatCurrency(Price + SelectedOptionsTotal())
End Get
End Property
End Class
and
public class DerivedItem : Item {
...
public new Decimal TotalPrice
{
get { return Price + OptionsPrice; }
}
}
As you can see, the DerivedItem.TotalPrice shadows the Item.TotalPrice property. However, when trying to retrieve the DerivedItem.TotalPrice value, I'm still getting the base object's TotalPrice value.
Why is the DerivedItem's property not being returned?
EDIT
I've actually found the problem! I am getting the wrong value in the JSON string being returned via AJAX. It turns out that the TotalPrice is being returned correctly, it's just being overwritten by the shadowed property call being made later in the JSON string. My new question, then, is how to I prevent the shadowed property from being serialized?
(This question has been rescoped here)
It may depend on how you are instantiating the object.
For example:
DerivedItem i = new DerivedItem();
i.TotalPrice();
Will call the shadowed version.
However:
Item i = new DerivedItem();
i.TotalPrice();
Will actually call the base.
Here's a nice explanation.
Of course if at all possible I would avoid shadowing.... :-)
Are you referecing TotalPrice from a reference to the base type?
Item item = new DerivedItem;
string s = item.TotalPrice;
Does setting <NonSerialized()> attribute on the base class property work?
I would like to extend the System.Web.HttpContext.User object (ASP.NET/VB.NET) so that it contains other fields besides just Name. I understand I can create an object that inherits the System.Security.Principal.GenericPrincipal class, but how do I store that in the Current.User object in a usable fashion. ie, I can do something like Current.User.UserID.
So far to achieve this I've created a kludgy workaround by using | delimited strings in the User.Name property and then splitting them, but it's getting kind of ridiculous.
Any suggestions?
Thanks!
EDIT: I have tried the following to no avail:
Imports System.Security.Principal
Public Class CurrentUser : Inherits GenericPrincipal
Private _totalpoints As Integer
Private _sentencecount As Integer
Private _probationuntil As DateTime
Public ReadOnly Property TotalPoints() As Integer
Get
Return _totalpoints
End Get
End Property
Public ReadOnly Property SentenceCount() As Integer
Get
Return _sentencecount
End Get
End Property
Public ReadOnly Property ProbationUntil() As DateTime
Get
Return _probationuntil
End Get
End Property
Public Sub New(ByVal principle As IIdentity, ByVal roles() As String, _
ByVal points As Integer, ByVal sentences As Integer, ByVal probationTil As DateTime)
MyBase.New(principle, roles)
_totalpoints = points
_sentencecount = sentences
_probationuntil = FixDBNull(probationTil)
End Sub
End Class
setting the object in my Global.asax Application_AuthenticateRequest function like so:
HttpContext.Current.User = New CurrentUser(User, userRoles, _
points, sentenceCount, probationUntil)
with a direct cast wherever the object is needed like so:
Dim thisUser As CurrentUser = DirectCast(Current.User, CurrentUser)
i also tried CType and it didn't work... my error is
[InvalidCastException: Unable to cast object of type 'System.Security.Principal.GenericPrincipal' to type 'myProject.CurrentUser'.]
i'm losing my mind here ... :( thanks guys...
anyone?
You can create your own Principal class with the required properties, that inherits from a Generic Principal, and then set the User property of your Current Context to be the a user of that type.
The example below is for ASP.Net MVC but a similar approach could be used with webforms.
You can do this in the PostAuthenticateRequest after a user is authenticated (in the Global.asax)
private void MvcApplication_PostAuthenticateRequest(object sender, EventArgs e)
{
SomePrincipal newUser = new SomePrincipal(User.Identity, tmpRoles);
senderRef.Context.User = newUser;
System.Threading.Thread.CurrentPrincipal = newUser;
}
You could then add a property or method in a base class of your page (or controller) for example that to wrap and type the Context.User principal to your Principal type and make sure you call it rather than calling the one on the HttpContext.
There are probably other solutions too!
Would this approach work for you? It looks a little involved but it really doesn't take too long to setup:
Create a 'base' class of your own, and have your pages inherit from that. For example, create a base class called 'BasePage' which inherits from System.Web.UI.Page.
Have your ASP.net pages inherit from your new BasePage class.
In the BasePage class, you can have a public property which contains the extra fields you want to store for your user (eg. BasePage.FirstName, BasePage.LastName). Better still, create a User object containing the extra fields, and expose that via BasePage, eg. "BasePage.Customer". This keeps things tidy if you plan to extend BasePage later.
You can then override the OnInit() of the base class to check for HTTPContext.Current.User.Name property, and fetch the necessary info from your DB to initialise your custom properties.
You can modify the code so that it won't need to hit the database each time the page is refreshed by using ControlState to check whether the custom fields have values before populating them again from the database.
Hope this helps...
Richard.