This question already has answers here:
OOP Terminology: class, attribute, property, field, data member
(7 answers)
Closed 5 years ago.
Can someone carefully describe the nuance between "attributes" and "properties"? I find them used interchangeably at times, and as differentiators at others.
The attribute and property terms are synonyms in most cases (also member, field), although property is often (python, C#, pascal, etc) used to describe the "virtual attribute" which is actually implemented by get/set methods (and attribute is used for regular attributes).
For example (python-like pseudocode):
class MyClass:
string first_name_attribute;
string last_name_attribute;
#property
def full_name(self):
"""Getter method returns the virtual "full name"."""
return self.first_name_attribute + " " + self.last_name_attribute
#full_name.setter
def full_name(self, string value):
"""Setter method sets the virtual "full name"."""
first_name, last_name = value.split(" ")
self.first_name_attribute = first_name
self.last_name_attribute = last_name
Here we have two "real" attributes - first_name_attribute and last_name_attribute and a "virtual" property - full_name.
Related
This question already has answers here:
How to create an instance of anonymous class of abstract class in Kotlin?
(2 answers)
Closed 2 years ago.
In C# I can:
var a = new { prop42 = "42" };
Console.WriteLine("a.prop42 = " + a.prop42);
Or do some other things, like serialization anonymous class instances (for using in js in browser). No interfaces or abstract classes used, fully anonymous class instance.
It is possible to make same thing in Kotlin?
Yes, you can do the equivalent in Kotlin:
val a = object { val prop42 = "42" }
println("a.prop42 = ${a.prop42}")
It's described in the language reference. See also this question.
This isn't often a good idea, though. Because the type doesn't have a name, you can't use it in public declarations, such as class or top-level properties of that type; nor can you create lists or maps of it. (In general, you can only refer to its named superclass — Any in this case, since you didn't specify one.) So its use is a bit restricted. (The lack of a name also makes the code harder to follow.)
I was wondering how you would go about creating a class to store strings and integers without knowing how many strings or integer you will have. For example lets say I make a class call Person.
Public Class Person
Public Property Name As String
Public Property Age As Integer
Public Property Gender As String
End Class
Now, to create a new person and give them their details I would do:
Dim Human As New Person With {.Name = "Bob", .Age=20, .Gender="Male"}
Well what if Bob has more information than just his Name, Age, and Gender? What if Bob also has a Height of 6ft and a Weight of 200lbs? How would I include this information in my Person class once its already been created?
What is this problem even called in the programming world?
The problem is called the open closed principle.
The solution depends on how bedded you are to it/SOLID principles. Things that spring to mind:
Simply adding the fields at a later date (this will violate the open
closed principle)
Extending the class (a new type of person with those new properties
for example)
The problem with the former (and a reason for OCP) is that it could have dependency implications for not only yourself but others. For example if you add property Age and start writing functionality that uses it what happens when you have a process that needs Age and you haven't set it.
This question already has answers here:
Why does this Kotlin method have enclosing backticks?
(6 answers)
Closed 4 years ago.
I need to make an API call out with a JSON object. This has worked for me using data classes and using the restTemplate.postForEntity(). The issue I'm running into is that the API is looking for a property of { "object": ... } and I can't create a val in the data class of object because it is a reserved keyword.
I tried to override the toString method to output "RequestClass(\"object\"=$obj)" but that didn't work. Is there another class that needs to be overridden with the restTemplate, or is there a different way to create a property with the same name as a reserved keyword?
That link helped fix it. Naming the variable `object` allowed it to keep that naming scheme. Thanks!
I'm not a big fan of using the backticks, because it pollutes your code. You end up having to use those backticks everywhere you want to reference that field. You could name it something appropriate that's not a reserved keyword, and use the mapping layer (presumably jackson) to change the serialized name:
#field:JsonProperty("object")
I tend to have to do this from time to time for json fields with the name "default" and such.
is operator overloading in fact polymorphism or parameter overloading?
Is it true that polymorphism usually refer to different classes responding to the same "message" (the method name) and do different things, so
bird.give_sound()
and
car.give_sound()
can do different things. And parameter overloading is more about talking about the same class, doing different things when the parameters sent along with the message (the method name) are different. So
bird.give_sound()
and
bird.give_sound(:frighten_sound)
can be different.
So operator overloading is strictly parameter overloading? like this following:
"foo" + "bar"
"foo" + 3
at least in Ruby, it is sending the + message to the string containing foo, the first line is sending with a parameter string, the second one is sending a parameter 3, and the + do slightly different things, but it is the same receiver class String
In the following example, it is polymorphism:
"foo" + 3
1 + 3
because the + message invoke different methods of different classes, but using the same message name +. So in these 2 cases, they are polymorphism, not operator overloading?
Is the above accurate and correct? Is there something that might be added to it or be corrected above?
Thank you for the clarification of context in your comment. Yes, I would say you are correct.
To summarize as short as possible...
Given identical method name (or "message"):
different behaviour based on parameter type is overloading,
different behaviour based on object type is polymorphism.
I'm going to take a stab in the dark and say that it's kind of (but not really) both.
Each object has to deal with the given object (the object on the right side of the operator) in a specific way. With strings, it seems that the toString method (or other language equivalent) would be used. So you would always be appending a string (passed to the method as an Object). (Polymorphism)
However, your object may need to perform different logic based upon the object given. For example, say you have a Student object. You may have one version of the method that takes a Class object, and adds it to the Student's class schedule. You then might have an overload that takes, say, a Book and adds it to the Student's collection of required reading material. (Parameter Overloading)
Polymorphism is when one data type dynamically behaves as another datatype.(Dynamic typecasting)
Shape
Qudrilateral
Rect
Rhombus
Elliptoid
Oval
Circle
Polymorphism is automatically selecting the proper area() method for a given object context
Operator overloading is when you select the correct area method for a method context(i.e. number of arguments passed or type of arguments passed) So if Rect had two area methods, one that accepted one argument(square) and one that accepted two arguments(any other rectangle)
So depending on the usage context, defining the operators for a given object can result in either Polymorphism or Operator Overloading.
Good Question.
The problem you found, its that we have 2 different concepts which similar syntax, that clash when applied programming: Overloading and parameter inheritance.
When I found operator overloading, I usually think in terms of overloading (methods) functions, to make more clear.
When I read these:
// (string) x = (string) "foo" + (int) 3
x = "foo" + 3
I think of these:
// (string) x = (string) "foo".concat((int) 3)
x = "foo".concat(3)
There is an additional problem, that each programming language handles operators with classes different.
I would suggest, to avoid operator overloading with object parameters, and explicity use functions.
In a passport there is a field: First Name, and that field has a value John.
I assert that it is correct to describe the relationship as follows:
Field First Name:
Has a name (First Name).
Has a set of valid values (e.g. defined by regex [A-Za-z. ]{1,30}
Has a description (name that stands first in the person's full name)
And Passport is a set of pairs (field : field value), such that:
passport has a field "First Name"
passport has a value for field "First Name"
Point here is that it is incorrect to say:
"First Name value is John";
The correct way (conceptually/academically) is to say:
"passport has a value 'John' for field 'First Name'".
In practical terms it means (pseudo C#):
struct Passport {
Map<Field, object> fieldValues;
}
struct Field {
string Name;
string Description;
bool IsValidValue(object value);
}
Q: Does this make sense? Any thoughts?
This is pretty subjective and entirely context sensitive, and seems like a silly thing to nitpick over.
Correct or not, if I'm discussing "passport" with a co-worker, I'd throw something at them if they corrected me every time I said "firstName is 'john'", and told me to say it as "passport's firstname field is 'john'". You'd just come across as annoying.
Well..not really in c# see Scott Bellware's answer to my question about C# not being Object Oriented (kinda).
In C# passport is a class so it makes perfect sense to say
"The Passport has a field FirstName"
For a particular instance "FirstName value is John".
Here the first clause describes the class and the next one the object. In a more OO language like ruby I think saying "passport has a value 'John' for field 'First Name'" would be equivalent, you're just describing two objects - the Passport prototype, and the instance of it in the same sentence.
I'm getting pretty confused in it myself though. The question is oddly phrased since there would doubtless be much more to a passport than just its fields, for example a long-standing and persisted identity.
If you are going to model such thing, then you may take a look at reflection API of java or c#. It is pretty similar to what you described. Class has set of fields, field has name, type and other attributes, not value. Object is an instance of class and you can ask object for the value of specified field. Different objects of the same class have values for the same fields, so you may say they share fields. So if you are trying to model class-based OOP then you are probably right.
However this is not the only way to do OOP. There is prototype-based OOP which looks differently, as there are no classes, only objects, so objects contain field with values so there is not much difference if you say that object contain field and field has a value.
So the answer to "Does this make sense?" I think is "yes" because similar thing is in reflection and is used widely. If it is right or wrong - depends on your needs.
UPD: regarding "value = Passport[Field]" vs "value = Passport.Field.Value"
I'd introduce one more passport to make it clear
firstNameField = PassportClass.Fields["FirstName"]
myName = myPassport[firstNameField]
yourName = yourPassport[firstNameField]
assumes that both passport have same fields, that makes sense. Having different passports with different fields may have a sense, just a different one.
No. At least in OOP, it's the field's responsibility to retain the value. Although the object is responsible for ensuring that value is consistent with the other fields or the object's constraints, the actual "containing of the value is the field's job.
Using your example:
Field First Name:
Has a name (First Name).
Has a type (int, string, object)
Has a description (optional)
Has a value
And Passport is a set fields:
May define constraints on such a field as defined by the model, ensuring the value and the object's state as a whole is valid