@M.Doerner ha nice! I'm not very familiar with the Observer pattern but it makes total sense, here's to "patterns naturally emerge"! ...I'll sneak it in along with the missing annotations, thanks!
I’m still really new to learning to program. Just learning the syntax for a few programming languages at the moment.
The courses I viewed for C# and Java touched only very briefly on getters & setters and it still didn’t make an awful lot of sense to me. So I researched them further and found tha...
If I understand correctly, those who argue against getters/setters would say that instead of:
Private FirstName as string
Public Property Get FirstName() as String
FirstName = FirstName 'yeah, I know, work with the pseudo code
End Property
Public Property Set FirstName (byVal theName as string)
FirstName = theName
End Property
One would use something like:
Private FirstName as string
Public Function GetFirstName() as string
GetFirstName = FirstName
End Function
Public Function AssignFirstName (byVal theName as string)
FirstName = theName
End Function
So effectively they're exactly the same thing the only difference is minor syntax. Is there something else I'm missing?
The 2nd example is just a Property Get and Property Set, but I have to come up with clever names that aren't Get and Set.
that is a side note to the question the OP asked, though. His question was in reference to Java and C#, so both of them have get/set.
Given a language that has get/set, though, is there any functional difference or is it merely semantics? If semantics, is there a real, tangible, significant difference, or has he just ID'd another holy war topic?
To me, the semantics is the whole point. In a language without properties, you have to rely on a convention and there's no guarantee that the convention is followed everywhere.
e.g. one API might have getFoo and setFoo while other API would have readFoo and writeFoo. That makes you wonder if there's a difference when in fact there may be none.
OTOH, in a language with properties, there's no double-guessing what foo should do.
I recall reading somewhere else that if there's side-effects, you should use function, otherwise use properties. However, in most (all?) properties-capable languages, there is no guarantee that a property isn't side-effecting, so that's yet another convention.
it makes no sense to require the calling code to do the property-change notification, because properties shouldn't encapsulate sideeffects
and the same applies for getters and setters
consider something like the following:
class QName
{
private string namespace;
private string localName;
public String QName {
get { return $"\{{namespace}\}{localName}"; }
set { /* parse value and store in separate fields */ }
}
// omitting implementations to acccess backing fields here
public String Namespace { get; set; }
public String LocalName { get; set; }
}
I see what you mean, but doesn't that break the encapsulation because qName.LocalName = "\foo\bar";? In my mind, a good API should have only one way to do something.
But I take your point that a property can have a side-effects. I was thinking about designs like this:
class Bad {
public string UserName { get; set; }
public string Password { set; }
public void Login();
}
class Better {
public string UserName { get; }
public void Login(string username, string password);
}
But when you think about it, that's kind of a vacuous statement.
Remember, at the end of day, it's just a some memory address that flips some bits around.
all fancypants like private access modifier, const statement, class block and whathaveyou are ultimately handled by the compiler. It's for our benefits, not so much for the CPU's benefits.
@FreeMan until you implement MVVM in VBA; then your ViewModel classes' Property Let procedures need to invoke OnPropertyChanged to notify the bindings - public fields are not strictly equivalent; properties are useful when there's additional logic needed beyond "assign the backing field value"
Same in C#: a WPF ViewModel that doesn't notify on property change won't work as intended ;-)
@MathieuGuindon it's not a difference between Public fields and Property Let/Get, it's the difference between Public Property Get PrivateValue and Public Function readPrivateValue.
Or, I don't understand what you're saying which is equally more likely
@FreeMan you have a BloatedUglyWalrus with 100 "properties". One of them is height. You are not sure if it's a property on the class. Want to hunt through get*** and set*** in the object browser?
@this No, but what's the difference between myBloatedUglyWalrus.Height = 30 and myBloatedUglyWalrus.setHeight 30 in terms of functionality? That, I think, is what the questioner was asking. In either case, I need to hunt through 100+ properties/methods looking for the proper way to assign the height of my BloatedUglyWalrus...
Sorry, a further input. The code that generates myResultHBT assigns vbnullstring to the array and not "" which is why myExpectedHbt was using vbnullstring in the first place.
ublic Function HelperGetHBT _ ( _ Optional ByVal ipStart As Long = 1, _ Optional ByVal ipRun As Long = 0, _ Optional ByVal ipEnd As Long = 0 _ ) As Variant
Dim myHBT As Variant myHBT = Array(vbNullString, vbNullString, vbNullString)
Dim myStartRun As StartRun Set myStartRun = HelperGetPositiveStartRunFromAnyStartRunEnd(ipStart, ipRun, ipEnd)
wow... Just ran across a 6-year-old answer from @Comintern on diy.se. I pinged him there, told him he's missed. I hope he comes back. I hope he's still with us...
VBA Rubberducking
VBA Rubberducking