I'm trying to code an implementation of Martin Fowler's recurring event calendar found here and I understand most of it but in all of his abstract classes he passed a string named eventArgs as a parameter.
For example:
class Schedule {
public boolean isOccuring( String eventArg, Date aDate )
public Vector dates( String eventArg, DateRange during )
public Date nextOccurence( String eventArg, Date aDate )
}
Anyone know what it's for? Is it just filler to show that this is just pseudocode and that I should put my arguments there?
In your comment, you write:
Okay so I think when he creates an instance of ScheduleEvent he would
have you add a string sort of like event = new
ScheduleEvent('myEvent') which would then be stored in the "event"
variable. When you call isOccuring on the Schedule you pass the name
of your event and it'll cycle through each SE object and see if they
have the same name to then check if it is occuring.
Correct. It's simply a label for the event whose recurrence you're describing with a TemporalExpression. If you wanted to integrate your implementation with arbitrary existing systems, you might even make that an Object instead of a String, and then you could pass in some Event object defined elsewhere.
Related
After reading this piece by Yegor about not using getters and setters, it sounds like something that makes sense to me.
Please note this question is not about whether doing it is better/worst, only if I am implementing it correctly
I was wondering in the following two examples in VBA, if I understand the concept correctly, and if I am applying it correctly.
The standard way would be:
Private userName As String
Public Property Get Name() As String
Name = userName
End Property
Public Property Let Name(rData As String)
userName = rData
End Property
It looks to me his way would be something like this:
Private userName As String
Public Function returnName() As String
returnName = userName
End Function
Public Function giveNewName(newName As String) As String
userName = newName
End Function
From what I understand from the two examples above is that if I wanted to change the format of userName (lets say return it in all-caps), then I can do this with the second method without changing the name of the method that gives the name through - I can just let returnName point to a userNameCaps property. The rest of my code in my program can still stay the same and point to the method userName.
But if I want to do this with the first example, I can make a new property, but then have to change my code everywhere in the program as well to point to the new property... is that correct?
In other words, in the first example the API gets info from a property, and in the second example the API gets info from a method.
Your 2nd snippet is neither idiomatic nor equivalent. That article you link to, is about Java, a language which has no concept whatsoever of object properties - getFoo/setFoo is a mere convention in Java.
In VBA this:
Private userName As String
Public Property Get Name() As String
Name = userName
End Property
Public Property Let Name(rData As String)
userName = rData
End Property
Is ultimately equivalent to this:
Public UserName As String
Not convinced? Add such a public field to a class module, say, Class1. Then add a new class module and add this:
Implements Class1
The compiler will force you to implement a Property Get and a Property Let member, so that the Class1 interface contract can be fulfilled.
So why bother with properties then? Properties are a tool, to help with encapsulation.
Option Explicit
Private Type TSomething
Foo As Long
End Type
Private this As TSomething
Public Property Get Foo() As Long
Foo = this.Foo
End Property
Public Property Let Foo(ByVal value As Long)
If value <= 0 Then Err.Raise 5
this.Foo = value
End Property
Now if you try to assign Foo with a negative value, you'll get a runtime error: the property is encapsulating an internal state that only the class knows and is able to mutate: calling code doesn't see or know about the encapsulated value - all it knows is that Foo is a read/write property. The validation logic in the "setter" ensures the object is in a consistent state at all times.
If you want to break down a property into methods, then you need a Function for the getter, and assignment would be a Sub not a Function. In fact, Rubberduck would tell you that there's a problem with the return value of giveNewName being never assigned: that's a much worse code smell than "OMG you're using properties!".
Functions return a value. Subs/methods do something - in the case of an object/class, that something might imply mutating internal state.
But by avoiding Property Let just because some Java guy said getters & setters are evil, you're just making your VBA API more cluttered than it needs to be - because VBA understands properties, and Java does not. C# and VB.NET do however, so if anything the principles of these languages would be much more readily applicable to VBA than Java's, at least with regards to properties. See Property vs Method.
FWIW public member names in VB would be PascalCase by convention. camelCase public member names are a Java thing. Notice how everything in the standard libraries starts with a Capital first letter?
It seems to me that you've just given the property accessors new names. They are functionally identical.
I think the idea of not using getters/setters implies that you don't try to externally modify an object's state - because if you do, the object is not much more than a user-defined type, a simple collection of data. Objects/Classes should be defined by their behavior. The data they contain should only be there to enable/support that behavior.
That means you don't tell the object how it has to be or what data you want it to hold. You tell it what you want it to do or what is happening to it. The object itself then decides how to modify its state.
To me it seems your example class is a little too simple to work as an example. It's not clear what the intended purpose is: Currently you'd probably better off just using a variable UserName instead.
Have a look at this answer to a related question - I think it provides a good example.
Regarding your edit:
From what I understand from the two examples above is that if I wanted
to change the format of userName (lets say return it in all-caps),
then I can do this with the second method without changing the name of
the method that gives the name through - I can just let returnName
point to a userNameCaps property. The rest of my code in my program
can still stay the same and point to the method iserName.
But if I want to do this with the first example, I can make a new
property, but then have to change my code everywhere in the program as
well to point to the new property... is that correct?
Actually, what you're describing here, is possible in both approaches. You can have a property
Public Property Get Name() As String
' possibly more code here...
Name = UCase(UserName)
End Property
or an equivalent function
Public Function Name() As String
' possibly more code here...
Name = UCase(UserName)
End Function
As long as you only change the property/function body, no external code needs to be adapted. Keep the property's/function's signature (the first line, including the Public statement, its name, its type and the order and type of its parameters) unchanged and you should not need to change anything outside the class to accommodate.
The Java article is making some sort of philosophic design stance that is not limited to Java: The general advise is to severely limit any details on how a class is implemented to avoid making one's code harder to maintain. Putting such advice into VBA terms isn't irrelevant.
Microsoft popularized the idea of a Property that is in fact a method (or two) which masquerade as a field (i.e. any garden-variety variable). It is a neat-and-tidy way to package up a getter and setter together. Beyond that, really, behind the scenes it's still just a set of functions or subroutines that perform as accessors for your class.
Understand that VBA does not do classes, but it does do interfaces. That's what a "Class Module" is: An interface to an (anonymous) class. When you say Dim o As New MyClassModule, VBA calls some factory function which returns an instance of the class that goes with MyClassModule. From that point, o references the interface (which in turn is wired into the instance). As #Mathieu Guindon has demonstrated, Public UserName As String inside a class module really becomes a Property behind the scenes anyway. Why? Because a Class Module is an interface, and an interface is a set of (pointers to) functions and subroutines.
As for the philosophic design stance, the really big idea here is not to make too many promises. If UserName is a String, it must always remain a String. Furthermore, it must always be available - you cannot remove it from future versions of your class! UserName might not be the best example here (afterall, why wouldn't a String cover all needs? for what reason might UserName become superfluous?). But it does happen that what seemed like a good idea at the time the class was being made turns into a big goof. Imagine a Public TwiddlePuff As Integer (or instead getTwiddlePuff() As Integer and setTwiddlePuff(value As Integer)) only to find out (much later on!) that Integer isn't sufficient anymore, maybe it should have been Long. Or maybe a Double. If you try to change TwiddlePuff now, anything compiled back when it was Integer will likely break. So maybe people making new code will be fine, and maybe it's mostly the folks who still need to use some of the old code who are now stuck with a problem.
And what if TwiddlePuff turned out to be a really big design mistake, that it should not have been there in the first place? Well, removing it brings its own set of headaches. If TwiddlePuff was used at all elsewhere, that means some folks may have a big refactoring job on their hands. And that might not be the worst of it - if your code compiles to native binaries especially, that makes for a really big mess, since an interface is about a set of function pointers layed out and ordered in a very specific way.
Too reiterate, do not make too many promises. Think through on what you will share with others. Properties-getters-setters-accessors are okay, but must be used thoughtfully and sparingly. All of that above is important if what you are making is code that you are going to share with others, and others will take it and use it as part of a larger system of code, and it may be that these others intend to share their larger systems of code with yet even more people who will use that in their even larger systems of code.
That right there is probably why hiding implementation details to the greatest extent possible is regarded as fundamental to object oriented programming.
In the active record pattern and in the builder pattern one may encounter so called "fluid" methods with non-verb names such as
public function carRadio(...);
public function driver(...);
The ellipsis (...) indicates zero or more arguments.
The purpose of the above is brevity. Sometimes exposing a public property is enough, but sometimes you want to do more stuff than simply assign an object.
e.g.
$kid = Kindergarden::find(33);
$kid->food($carrot);
assert($carrot == $kid->food());
Roughly, this means give some food to the child, but in the food method you may want to check for allergies or some such.
A bulilder-pattern example could look like:
$threeThousandWatts = Generator::create();
$threeThousandWatts->wires($w)->fuel($gas)->schedule($timeSlot);
...you get the idea.
The question is, what do you (literature you have read) call a mutator that is also a an accessor?
PS. This is not a for a public API. It's just a generic question.
I have a class with one private field:
class Person {
string name;
public void setName(string name);
}
Then, using some object which is responsible for interacting with user (in this example by command line), I want to change the value of this field:
Person somePerson;
CommandLineView view;
somePerson.setName(view.askUserForName());
It works. But I don't like using set function as it exposes class members.
Therefore I started looking how to avoid it.
New implementation looks like this:
class Person
{
string name;
public void changeName(view) { name = view.askUserForName(); }
}
and:
Person somePerson;
CommandLineView view;
somePerson.changeName(view);
Now Person does not expose its member. Moreover this class is responsible for logic related to changing name (for example function changeName could also update database, notify interested parties etc.
The question is: Is such kind of refactoring a good practice? Or maybe implementation with setter was better, even if it break encapsulation?
I think there should be no method to set the name at all, it should be a constructor parameter:
Person somePerson(view.askUserForName());
Problem with your approach is that you first create the object which is not fully initialized, so is dangerous to use: Person somePerson. What if you forget to setName? Will your code still work with this "empty" person?
And then you allow to directly modify the internal state with setName method, which is also not good.
Using the constructor parameter you avoid both of these problems.
As for the original question - I don't think there is big difference between the two methods.
The result is exactly the same - you call the method and the internal object state changed. You can name it setName or changeName, result is the same.
The second method with changeName(view) actually is worse because you also introduce the dependency of the Person on the View object.
Now, if you want to change the name, you always need to create the View object first.
I've been overloading procedures for some time now, but recently asked myself what the actual advantage is in comparison to just adding a procedure with a slightly different name.
So basically, why should I use
Public Void DoSomething(Int FirstParam, String SecondParam)
Public Void DoSomething(String FirstParam, String SecondParam)
in stead of
Public Void DoSomething(Int FirstParam, String SecondParam)
Public Void DoSomething_V2(String FirstParam, String SecondParam)
If anything, a different procedure name actually might make it less confusing to see which procedure is called.
Will you remember, when you're writing code a few months from now, that DoSomething_V2 was the one that took two String parameters? V2 is a spectacularly bad name.
Now if you're asking why not name them sensibly, then you get from new File(...) to File.getInstanceFromParentFileAndChildString(File parent, String child), File.getInstanceFromPathString(String path), File.getInstanceFromParentAndChildStrings(String parent, String child) and File.getInstanceFromURI(URI uri).
This is the way Objective C went, and one of the biggest complaints from newcomers to the language is its amazing verbosity.
That is because you don't have to keep inventing the names. To make the function more easy for others to recognise that it takes two strings, you will have to name the same function like DoSomething_TwoStrings.
If there is another function that takes one string and one int, you will have to name it like DoSomething_String_Int.
What if the order of the elements is to be changed and created into another function? If you choose to name your procedures as V2 and V1 etc., this will create another layer for users to remember. What does V2 take as input, and what about V1. This all creates hundreds of more names than a user really has to remember if you don't use overloading.
Your program will also be clear due to having less vocabulary and smaller function names. Once you know that IDE will clearly give you intellisense as to all the overloads and you can choose what you want, it is a piece of cake to use overload and is lot less cluttery.
I have an Entity which has an id and a title. The id is always the same but the title value change given a locale. I found three way to modelize this :
class Entity
String getId()
String getTitle(Locale)
or
class Entity
String getId()
LocalizedEntity getLocalizedEntity(Locale)
class LocalizedEntity
String getTitle()
or
class Entity
String getId()
class LocalizedEntity extends Entity
Locale getLocale()
String getTitle()
I tend to prefer the first one because it does not corrupt the way you modelize the Entity, it is just a kind of view of your object. The second is the worst case for me.
Which one is better ? Is there another way ?
To my mind, that your data are localised should not impact on your object design, so I would go with your first option.
We built a localisation engine in my day job, a few years ago, and that is the model we used, where the Locale object was specified with three properties (ISO 639-1 α-2 language code, ISO 15924 α-4 script code and ISO 3166 α-2 territory code, together making up an IETF language tag, like en-Latn-GB, zh-Hans-CN, sr-Cyrl-RS and so on).
I hope that helps, though I'm guessing you probably made your decision last year, given the date of your question.