Not taking performance into account, it can be handy to use a static variable inside the getter for a readonly property since:
It allows you to save information between get calls
The information is only accessible by the property
The problem is that it does not seem to be accessible by the property's setter. Is this correct, or am I missing something?
No, because that does not make sense. You could expose a static value via a read only property, sure. By the very definition of "Static" you cannot assign anything to it, which is the only purpose of the Set method of a property.
Edit: To clarify, you could do something else with the inbound 'value' of Set... but then you aren't really setting the member variable the property exposes anymore, which sounds like you just need a Public Class Sub that does whatever your weird Set would do.
Related
I am tasked to make the B2Bsellers plugin work for our use case.
I need to access data from EmployeePermissionTranslationEntity. The plugin has not defined a getter for the field i need to access.
I can see that the data exists though debugging, but the getter is not defined. How can I extend this entity and manually add the getter though my own plugin?
The \Shopware\Core\Framework\DataAbstractionLayer\Entity class defines a magic getter method https://github.com/shopware/platform/blob/v6.4.15.2/src/Core/Framework/DataAbstractionLayer/Entity.php#L44
so you should have access to it with $employeePermissionTranslationEntity->propertyName
Could you maybe tell me which data you want to get from EmployeePermissionTranslationEntity
Currently you only can get the name.
This is the only available translation for EmployeePermission
Using code analysis on my program I often get this warning:
CA1051 : Microsoft.Design : Because field 'Form1.Testcode' is visible outside of its declaring type, change its accessibility to private and add a property, with the same accessibility as the field has currently, to provide access to it.
So it tells me to either change the code from this: Public Testcode As String
To this: Public Property Testcode As String
Or to this:
Private _testcode
Public Property Testcode As Object
Get
Return _testcode
End Get
Set(value As Object)
_testcode = value
End Set
End Property
So my question is, what is the difference between the 2 code suggestions.
Is one faster than the other or does it prevent bugs or anything else? I've been using the first code since ever and never had issues with it neither feeling lags or something else.
Saying I want my program to be as fast as possible should I change the Code that I have to the Property code and if yes, which to choose?
The point of properties is that they behave like fields from the outside but like methods from the inside. In fact, once your code is compiled, the getter and setter of your property actually are methods. Java doesn't support properties but even there the convention is to declare a field private and then declare two methods for getting and setting the field value.
Always use properties to expose data publicly. If nothing else, it means that you can bind objects of that type because properties support data-binding while fields do not. It also makes it far less likely that you will need to change the type interface if you need to change the implementation later.
As for how to implement the property, always use an auto-property, i.e. the one-line option, unless you need to add extra code to do things like validation or raise an event. If you write an auto-property, the private field is still created behind the scenes - you can even access it in code - and the compiler still creates the getter and setter methods. In short, prefer this:
Public Property Data As SomeType
to this:
Private _data As SomeType
Public Property Data As SomeType
Get
Return _data
End Get
Set
_data = value
End Set
End Property
An example of a situation that would require the full property is below:
Private _number As Integer
Property Number As Integer
Get
Return _number
End Get
Set
'Validation
If Value < 0 Then
Throw New ArgumentOutOfRangeException("value", $"'Number' must not be less than zero.")
End If
If _number <> Value Then
_number = Value
'Change notification.
OnNumberChanged(EventArgs.Empty)
End If
End Set
End Property
Public Event NumberChanged As EventHandler
Protected Overridable Sub OnNumberChanged(e As EventArgs)
RaiseEvent NumberChanged(Me, e)
End Sub
Is one faster than the other? No.
Does it prevent bugs or anything else? Yep.
In VB, Public Testcode As String and Public Property Testcode As String look pretty much the same. But let's put the syntax aside, we are speaking about member variables and properties here.
Member variables are variables you have to use in your classes when they have to "live" as long as the class instance does. It is basically the same as every other variable but without defined context (say the end of a method for example). You'd use them typically to hold kind of a state like whether the user had confirmed a message or anything like that. If this kind of information is important for the logic of your class but not for others, you have a perfect candidate for a member variable.
Properties are not very different here and can technically be used the same. However they are part of an external interface. If you have to hold information that is important to your class and to other classes (using your class) as well, you have a perfect candidate for a property. This could be the border color of a button for example. Other classes might set the color by a given design and the button itself needs it to render the border accordingly, of course. Public methods and properties build the interface other parties can interact with. There are some useful answers here on StackOverflow, I'll link them below instead of copying their content.
Why should we care?
So we're basically talking about encapsulation and information hiding. But let's look at that in a more practical example.
Look at your desktop PC. Turn it around and take a look at all the connectors it exposes. This is the public interface of the machine. That's what you as a consumer of the machine can interact with. You see USB ports, HDMI connectors and so on. You don't need to know the internals of the machine to understand where you can connect a mouse to or how you can attach your HDMI-to-DisplayPort adapter. In fact, it would be very confusing if every internal connector would be available to you on the backside of your PC. It would add so much unneeded clutter and it would make things dangerous, too. Because you'd have no chance to know what all these pins and connectors are made for. The hardware manufacturers could not rely on expected conditions because anyone might have messed things up unknowingly from the outside.
Everything you as a consumer can interact with is made public with the interface of standard connectors. Everything the machine needs to work internally is kept away from you to avoid confusion about things you don't need to know about and make sure noone messes with the internal state the machine has to rely on.
So you could say "lets do everything public because I have no secrets" but in fact that would make the class very hard to understand from the outside. It would make it easy to break things unknowingly by setting members from external code which your class handles internally and has to rely on.
Another aspect we as software developers have to keep in mind: Maintainability. If you have a lot of public members, you are pretty locked when doing refactoring because you'll never know how anyone out there is using them. Keeping a clean interface to the outside is important to be able to change things internally later on.
See:
Internal applications - why not make everything public?
Why shouldn't I be using public variables in my Java class?
See Auto-Implemented Properties:
When you write code for an auto-implemented property, the Visual Basic
compiler automatically creates a private field to store the property
variable in addition to creating the associated Get and Set
procedures.
So using the shorthand notation:
Public Property Testcode As String
Results in the same code as the longer verbose property, WHEN YOU COMPILE.
There is no difference in the end.
In VB.Net can you declare variables locally (in a method) and have them have a global scope?
I'm new-ish to VB.Net and am trying to figure out some of the ways the language works. In a previous project I did with C++ I was able to inside of a method declare a variable as global, saving memory space until the first time that method was called and the variable was instantiated.
Just curious if this is something that is possible with VB.Net.
Encapsulation in .NET can make it difficult to implement a global variable in the way you are thinking of one. The closest solution may be to declare a public variable in a module, but it isn't immediately available inside another module.
The way I usually do what you're thinking is to create a singleton class "globals" that contains member fields representing the global variables I want to move around, then I just pass my "globals" instance as an argument.
Public Dim myGlobals as GlobalClass
myGlobals.someVariable = "preserve me"
Then making them available to be accessed by the method: someMethod(myGlobals) will pass them by reference by default.
So Jacob posted an pretty good answer to my question. After a bit more researching, I think my best bet is to do something similar to the following:
Class ScopeTest
Private randVar As Object = Nothing
Sub Initialize()
randVar = New Label()
End Sub
End Class
Essentially, create the variable at the highest level scope I need it, and set it to Nothing so that no data (should be) allocated to it, but the variable name has the appropriate scope. Then I just instantiate the variable whenever I call it the first time, and then it will be implemented throughout the rest of the code.
Obviously the largest pitfall with this setup is if I go to call the object while it is equal to Nothing. This will require me to add in some If Not IsNothing statements to the code, but since I can't seem to find a better way to go about this, it's what I will be doing at the moment.
I've been battling with AS3 for a little while now, and I'm working on a simple application using only actionscript and the FlashDevelop/flex-compiler combo. I've hit a bit of a wall in my fledgling OOP understanding, and I'm wondering whether someone might be able to point me in the right direction. I have genuinely read several books, and spent many hours reading online tutorials etc, but something's just not clicking!
What's baffling me is this: When something is declared 'public', according to what I read, it is therefore available anywhere in the application (and should therfore be used with care!) However, when I try to use public properties and methods in my program, they most definitely are not available anywhere other than from the class/object that instantiated them.
This leads me to conclude that even if objects (of different class) are instantiated from the same (say 'main') class, they are not able to communicate with each other at all, even through public members.
If so, then fair enough, but I've honestly not seen this explained properly anywhere. More to the point, how do different objects communicate with other then? and what does Public actually mean then, if it only works through a direct composition hierarchy? If one has to write applications based only on communication from composer class to it's own objects (and presumably use events for, er, everything else?) - isn't this incredibly restrictive?
I'm sure this is basic OOP stuff, so my apologies in advance!
Any quick tips or links would be massively appreciated.
There are different topics you are covering in your question. Let me clarify:
What does the modifier public mean?
How can instances of the same class communicate to each other?
--
1.
In OOP you organize your code with objects. An object needs to be instantiated to provide its functionality. The place where you instantiate the object can be considered as the "context". In Flash the context might be the first frame, in a pure AS3 movie, it might be the main class, in Flex it could be the main mxml file. In fact, the context is always an object, too. Class modifier of your object public class MyClass tells your context whether it is allowed to instantiate the object or not. If set to internal, the context must live in the same directory as the class of the object. Otherwise it is not allowed to create a new object of the class. Private or protected are not valid class modifiers. Public class ... means that any context may create an object of that class. Next: Not only instantiation is controlled by these modifiers but also the visibility of a type. If set to internal, you cannot use an expression like var obj : InternalType in a context that does not live in the same directory as Internal type.
What about methods and properties? Even if your context is allowed to access a type, certain properties and methods might be restricted internal/protected/private var/method and you perhaps are not able to invoke them.
Why we're having such restrictions? Answer is simple: Differnent developers may develop different parts of the same software. These parts should communicate only over defined interfaces. These interfaces should be as small as possible. The developer therefore declares as much code as possible to be hidden from outside and only the necessary types and properties publicly available.
Don't mix up with modifiers and global properties. The modifier only tells you if a context is allowed to see a type or method. The global variable is available throughout the code. So even if a class is declared to be public, instances of that class do not know each other by default. You can let them know by:
storing the instances in global variables
providing setter such as set obj1(obj1 : OBJ1) : void where each object needs to store the reference in an instance variable
passing the object as method arguments: doSomething(obj1 : OBJ1)
Hope this helps you to more understand OOP. I am happy to answer your follow up questions.
Jens
#Jens answer (disclaimer: I skimmed) appears to be completely correct.
However, I'm not sure it answers your question very directly, so I'll add a bit here.
A public property is a property of that class instance that is available for other objects to use(function: call, variable: access, etc). However, to use them you must have a reference (like a very basic pointer, if that helps?) to that object instance. The object that instantiates (creates, new ...) that object can take that reference by assigning it to a variable of that class type.
// Reference is now stored in 's'
public ExampleClass s = new ExampleClass();
If you'd like to, you do have the option of making a static property, which is available just by knowing the class name. That property will be shared by all instances of that class, and any external class can refer to it (assuming it's public static) by referring to the class name.
A public property is referred to by the reference you stored.
//public property access
s.foo
s.bar(var)
A static property is referred to by the class name.
//static property access
ExampleClass.foo
ExampleClass.bar(var)
Once you've created the instance, and stored the reference, to an object, you can pass it around as you'd like. The below object of type OtherExampleClass would receive the reference to 's' in its constructor, and would have to store it in a local variable of its own to keep the reference.
public OtherExampleClass s2 = new OtherExampleClass(s);
In VB.NET, what are the advantages of using the Property keyword rather than:
Private MyProperty as String
Public Sub setP(ByVal s as String)
MyProperty = s
End Function
Public Function getP() as String
return MyProperty
End Function
Coming from Java I tend to use this style rather than Property...End Property - is there any reason not to?
You are doing the work that the compiler does. Advantages of the Property keyword:
You can't accidentally mix up the getter and setter property type, a real issue in VB
No need for the awkward get and set prefixes, the compiler figures out which one you want
Data binding requires a property
You can take advantage of the auto property syntax, no need to declare the private field and only a single line of code.
The same declaration in VS2010 using the auto property syntax:
Public Property P As String
The compiler auto-generates the getter and setter methods and the private backing field. You refactor the accessors when necessary.
You will get some added benefits from properties that you will not get from using getters and setters.
Like reflection will find all your properties easily because there are methods for that.
ORM's for instance will easily be able to find your properties but it will be harder for them to find the getters setters because the convention is to use the properties.
So functionally they might be the same but the convention is to use properties.
Functionally there is no difference but for me the usage of Properties is a cleaner implementation. Look here
.Net 4 also gives AutoImplement proeprties to VB.net here wher ethe private backing variable is automatically created by the compiler resulting in much cleaner code and less boiler plate code to write.
Using Properties makes the visual studio editor able to show/edit it in the property grid. If you are creating a control or dll that other will use they are used to be able to change design-time properties in the property-grid.
Also the property-grid-control will be able to pick that up if you add the control to the form and then set the SelectedObject-property of the grid to an instance of your class/control.