28
When I am studying object-oriented programming, at times I hear about fields and attributes of a class, but the two seem to be different definitions to refer to the same thing. What’s the difference?
Taking advantage, we can say that a property is an attribute or a field?
28
Quite a controversial subject, but it shouldn’t. Everyone can have their opinion, they can follow a specific school, but there’s evidence that most of the use is what I put here. I do not deny that it is used in other ways, I quote.
It is a specific feature that an object will have, but it is not well defined how this feature will be available in the object. It doesn’t matter if it’s a field, a property, a method, or something else, or even a set of these mechanisms.
The term is usually used more abstractly, in general application design and not in programming. There are many people who use in programming as if it were a field, which I think is mistaken, even if it causes little harm.
Sometimes it is used as if it were a property, and there is more or less correct. See the definition of property below.
An attribute is a set of rules, is as it should be, behave, something that is proper to that type of object.
So a possible definition would be that it is a set of state, optional, and optional behaviors, which has a focus to suit a specificity of that object, to determine a feature that that object will have. Not that it’s the only way to see the concept, but it’s acceptable in some context.
That one article by Martin Fowler works with this definition. Not formally, the article is a little vague, my interpretation was that.
The state may eventually define type, format, default value, other restrictive characteristics. I don’t know any mechanism that stores state in a code that is different from variables or constants (in the sense of read-only after initialized).
Behaviors are usually methods, but there are other ways of specifying behavior in some languages, although in the end it is indirectly something very like a function.
Often the attribute has only one field in its definition, hence the idea that they are the same thing. Attribute is conceptual, point! If it is on a different level from other terms, like property, how could it be the same thing?
I believe it can be used as field name, which is different from being the country. For example: "social reason" is the field name that holds the name of legal persons, so "social reason" is an attribute of a field that has this characteristic. This fits into the idea of being an accessory information, descriptive, modifiive, and not the main information of the object, not the value.
The definition of the utluiz response seems to go a bit along this line, although more collateral, since the definition of the field indicates this, the attribute indicates something else in a specific context, which I disagree with because it ignores everything that has been said here that it is confusing to use the same term for more than one concept or mechanism, or that there are already other mechanisms using the term attribute. It seems to me a view of the type "everyone says this so I will accept that it is this, even if it has flaws in the definition". And I obviously disagree with the conclusion that it’s artificial, unless it all turns out to be artificial. I only agree with the fact that there is application in a specific context. And this answer is all about resolving conflict when contexts intersect and terms create confusion. So the distinction is not irrelevant, and it shows how OOP brought more confusion than solution.
It is common languages nay cite attribute as their mechanism (look there), or else the term be used for another mechanism different from what is said here, although I think the term should only be used for this.
C++ also uses the term for modifiers that qualify a part of the code, and not to define a member of a type. C also.
In Java they use the term for the parts of the annotation, which is also a qualifier, ie works like in HTML.
Python also, although use with a complement to disambiguate.
In the PHP community looks like you’re going the same way.
There’s even a paradigm over attribute.
Note that there are attributes that are part of the language. static, private, readonly, virtual, async, abstract, final, all these things are attributes.
In UML it is common to use the term. But they often use field as well. I have not seen property where I searched, at least for this.
I did not find in the specification what is the correct term, when to use one or the other, or even if it is right to use both.
I find it strange that a modeling language should involve itself with implementation detail, and if so, I find it unnecessary. In practice many people consider, since its use is quite restricted among programmers (even if it has many thousands of them using, it is still far from the total of millions), and my opinion is that the majority that uses are without real earnings. It’s not just my opinion, has data.
I thought UML was about formalisms. If a definition more or less serves no reason to use UML or similar tools.
Have you ever stopped to think that the formalization of UML is wrong? It can happen, there are numerous cases that this occurred. People do not dispute.
A tool created to unify communication in a project that says opposite What people use in languages is something fundamentally broken. But everyone can have whatever opinion they want, including that all the languages that are like that are wrong.
Interestingly UML is defended by Agile adopters. I don’t understand this.
The term is considered by many as vague, ambiguous (see just below the dictionary citation in yellow below) and controversial (in each place has a different definition), so it should not be applied formally, and should not be taken as absolute truth, as also many do.
Some sources have consolidated the idea that both are the same thing and some people think that this cannot be contested. But there are sources showing otherwise.
It’s kind of like Duck Typing. A term that either means nothing, or says something that already existed and didn’t need it.
I found a "school" that uses the term to indicate a characteristic associated with a class or member of it, eventually even in other things. In fact it is the definition used in Wikipedia, and how the term is effectively used in many situations. And used in several places.
Then field would be a noun, method a verb (its action in itself does not cease to be a noun), just as classes do not cease to be nouns in a certain context, and attribute would be an adjective that is always applied to nouns).
This being correct, and I think it is, my answer that generated some controversy is correct not only in the context of . NET.
There’s even a paradigm that preaches its use in this way.
UML prefers to call stereotype (again, unlike anything people actually use).
I saw that in some places is used in exactly the opposite way. An attribute would be like a field (noun), and it would have properties (adjective). I found horrible. But it is a matter of point of view. For me attribute implies being an adjective, a noun could only be the concreteness to apply the quality.
a tri Bu to male noun
Own and inherent quality.
College.
Distinctive sign.
[Grammar] . Adjective (or adjective ) that qualifies a name.
Predicative name.
"attribute", in Dicionário Priberam da Língua Portuguesa [online], 2008-2013, https://www.priberam.pt/dlpo/atributo [consulted in 14-01-2018].
In various contexts the computation attribute is a metadata (adjective) and not the data (filing cabinet, HTML and other markup languages, language analysis, in addition to the aforementioned used as an annotation).
It seems more like something defining a style, a way, but not a part of an object. Note that the use of the term as if it were a field is exactly a part of the object, is very concrete.
It is true that there is use as a column of a larger object. I think it was an error that perpetuated in OOP.
What do you call the characteristics of a column? It seems that this was not defined. Maybe they call it property :P. And maybe it explains why some schools go this way. Enough to be ironic, because it is common for proponents of OO to reject relational algebra in some degree.
I believe that at the time they saw the attribute as being something other than a column (field), and it was a bad definition. Or not, it may be that they defined right and followers did not understand that the attribute was conceptual, and the concrete implementation would need something concrete, as the physical column (field) or virtual (property), will know.
Or you’re right and that’s why the languages would be wrong, which would be unfortunate.
Whoever finds something, I’d like to know.
Why don’t we use the term column then? Another misfortune. The implementations of the relational model call, and I find it more important than the theoretical concept.
To science defines as a characteristic of an object and not a part of it.
It even says that a variable is a set of attributes. We developers create a field with name linked to a memory position (variable), with a domain (type), life time, scope and visibility defined, a default value, boot form, mutation capacity, alignment, shape and location of allocation, constraints, Labels and tags, and other useful penduricalhos (not all languages allow all this syntactically and need to be emulated with methods and manual discipline).
On the other hand, in the same entry it seems that the attribute is the initial definition proposed here, which would be a specific information. How it is obtained doesn’t matter, so it would make more sense to confuse attribute with property than with field.
In both cases field cannot be confused with attribute.
It is also said to be ancillary information that leads to the understanding that it is a metadata, something that modifies a characteristic of an object, as opposed to being a part of an object.
In ontology speaks of characteristics, leaves open what may be a part, which is in line with what has been set since the beginning of this answer. It can be a part only by circumstance, if it is what defines a quality of the object.
Apparently Ruby treats as the adjective value field (instance variable). I can accept this definition. The article was not proposed by me, I took from another controversial response on the subject.
And I understand that Eric Evans' Domain Design Driven (DDD) says the same, as the same answer shows. There says nothing which attribute is a field or property. There it indicates to be a value, including because no one changes field, changes the value of the field, it is possible to interpret attribute as its field value, even if you do not like this definition. But it gives margin to understand that it is only the characteristic that the value can have, what, in this hypothesis, would refer to be only an annotation of the field or property.
Interestingly in this excerpt the answer reneges what was said in the previous section stating that an attribute is not a field.
Same goes for Gof’s book on Patterns design. It is possible to interpret that they are talking about the same thing, but they may also be talking about something else. It’s not explicit, so it’s not evidence that the terms are interchangeable.
In the following section statements are made that have nothing to prove and in what context they were used. And the section ends with a clear false information, as my answer there shows.
And the last book quote in the section is the same, says it’s evidence something that doesn’t lie in the quote.
I agree with the conclusion (although it has some less relevant false details), although it does not answer the question there, it would be good here. There we talk about the specific mechanism. Here we talk about the conceptual level. The conclusion says that the terms are equal, but shows that they are different when it says that the property is the implementation mechanism of the attribute. All the discussion there (already deleted) was about using the correct terminology, which was not done.
Then time speaks of the general concept that adjectives the object hour of the mechanism to modify something into a noun. Never from the field itself, if you conclude that where you may be speaking can also be a misinterpretation.
If a number of tools and literature define wrong terms, you can’t trust them. I’ve said this in another answer from me (link in the end). And I wouldn’t know which is more reliable. Again, the term is bad.
It is what stores an object state. It is one of the ways to create an attribute. It is a variable. It is a piece of data from a whole (a record of an object). It is a concrete and existing mechanism in language implementations and other tools.
It is often called the member variable. I see much use even in cases where it is immutable (see about constants and read-only variables).
The term variable is not conceptually the same as field, read on link above what is a variable. In more esoteric implementations it is possible for a field not to be a variable. In practice they are.
The only term here that is well defined, everyone agrees, and in any context (of our area) is not ambiguous.
In POO he is synonymous member of data. Which is different from being interchangeable (two distinct things that serve the same purpose).
Smalltalk does not use the term and prefer attribute. If programming in this language it would be better to use its term. But who programs in Smalltalk? A technology that is unsuccessful can dictate what is right when others say the opposite? It stands for debate elsewhere.
Is a more concrete (mechanism) way of defining an attribute and a general way of defining a characteristic of the object. It is common for a property to have one or more related fields to keep the feature stored. But it is possible to have only one or more methods (usually getters and setters) that provide these characteristics without being intrinsic to it.
So yes, a method can be considered an attribute of an object depending on how it is defined. He does something that delivers a feature of the object.
Some languages prove syntax that unifies the idea of field and access and mutator methods for the property, what can make its consumption indistinct, as a variable of the object. There are those who consider only this form as property.
Some people consider that the property is(are) the characteristic method(s) and the somewhat distinct field, and that the attribute would be the conjunction of both.
But there are those who think exactly the opposite, that is, the attribute would be the field, and the property would be the set, which seems to me very wrong, but it is my point of view.
Some consider that property is the public form of the feature and the private field and methods attached to it would be the implementation detail of the feature. Therefore a public field would be a property as much as public methods are. And a private method could never be a property. Makes any sense.
Some people consider that it is only property to allow access to and/or change the state, even if indirectly (by calculation, for example). What would make a public field a property.
In various fields of knowledge property really is a synonym of attribute in many cases. Which, technically speaking, would make the term unnecessary. Interestingly I don’t see many people exchanging between attribute and property, occurs more between attribute and field.
I think the term should be reserved for the mechanism (as it defines the Wikipedia), making him less ambiguous. Leave the attribute to qualify something, whether in the implementation (accessory information of a part of the object), or conceptually (feature of the object, without detail of implementation).
Depending on the language you can use the term in a specific context or in a specific way.
That is, the term is bad except in a specific context, such as what C# uses, for example. And it helps to understand the link placed by utluiz in his reply.
The question did not seem to care about this, but by the AP’s own answer, it does. I think this has already been explained in What is the difference between class instance variables, automatic (local) and static duration?.
Note that I am talking about the object, all this applies to the class as well. What is different? What refers to the object is what it will have in each instance modeled from the class (or prototype), and what refers to the class itself only exists singularly in the code, there are no instances, it is something that only makes sense to exist in the model. In other words, it’s what they call static.
Like almost everything that is said in object-oriented programming, there are those who think differently and can be challenged, one of the reasons I am not a fan of the paradigm, and so the use of more pragmatic where their basic ideas are useful, no idealism and purism.
It may be a misinterpretation of text that has perpetuated itself, as has happened with several others ("goto is harmful", "premature optimization is evil", "Java runs on all platforms", "everyone should learn programming", and things like that).
The fact that someone wrote it in an article does not make it true. The fact that there are several people quoting and copying this article as well. This just means that some people think this way.
So I prefer to say it has several definitions, choose yours, because I can’t prove that my definition is the right one.
The evidence only shows that there are controversies. But not to be on the fence I prefer to base myself on what seems more grounded, more solid, more coherent, more intuitive, even if this is subjective.
I mostly ignore articles that are ambiguous. We have to separate what is disclosure article and knowledge exposure article.
I’m still learning about OO, and I’ve been doing it for the last 30 years, in the most recent I’ve made great progress and Desmistifying things I’ve learned wrong, changing my mind.
Since there are controversies in definitions, I create my own definition based on facts and axioms already tested and less on opinions and interpretations with low foundation.
Do not take this as a definitive and universal answer, the subject is more complicated than it seems and without mastering it can not do right.
Since it’s very common to use attribute as a field, and most of the time it works, understand that in practice, they’re almost always talking about a field when in fact they use the term of a set of characteristics of a part of the object.
But we still can’t say that the terms say the same thing. It would be the same as saying that abstract class, interface, trait and mixin are the same thing. in fact these concepts are more related than the terms of the question.
It amazes me when someone disputes whether the term is being used correctly and defends ambiguity. Give correct name to each thing, do not accept synonyms, unless in informality, even so avoid. It’s bad to have two names for the same thing and it’s bad to have two things with the same name.
It is also useful to know What is the difference between a class and an object?.
You might also want to know Concept of class, entity and objects.
I accept contestations and suggestions and edit to reflect them.
I’m still going to put more evidence than I’m talking about, especially on property that has many definitions.
The term element could also be used in OOP? Ex: "such object elements". I see that it is quite common in markup languages, but, I do not know if it is common in OOP.
Some people use it, I don’t like it. I think it refers more to a collection of data, like the array. I prefer membership to an object. It is the question of the set being homogeneous or heterogeneous, few and defined items or many and indefinite amount.
Can attribute be a property? Therefore standards and standards are good to discuss this. http://swebokwiki.org/Chapter_2:_Software_design This second is worth having NBR ISO/IEC 12119;
I think this discussion is cool, the best so far about concept.
@alxwca the idea was this, and great link, I’ll dissect it :)
A static variable or constant would still be considered a field?
@My understanding is yes, and I’ve never seen anything to the contrary.
11
The other answers are interesting in how they unravel the different uses of terms attribute, field and property. They are useful for reflection. In specific contexts, paradigms or technologies there really are differences between them.
However, if, after reading answers, articles, and encyclopedic definitions, you still get confused, take this as strong evidence that the differences are artificial.
When analysing such terms comprehensively, the only possible conclusion is that there is no definitive terminology.
The best, in my opinion, is to avoid arbitrary and artificial distinctions, with the exception of specific technologies or paradigms where it makes sense.
I will try to demonstrate this in the topics below...
This term was probably widely used as an analogy to physical forms. When you open an account at the bank or go to clean the feedback of a proof, you are filling the fields of the forms with their respective values.
In an information system, fields can reference the elements that define a database table, the different spaces in a data structure allocated in memory or the space on the screen that the user has to enter a specific data.
In both cases, people commonly apply the term both to the definition of the field and to the field itself in a form containing a specific value.
Examples:
Fill in the name field.
The value of the name field is "Maria".
The term field does not match the object orientation paradigm.
Sometimes referred to as characteristic, the term makes perfect sense when we speak of a class or object. In OO, a class has members, which are commonly divided into attributes and methods (characteristics + behavior).
The term can be used both for the definitions of a class and for the concrete value of an object.
Examples:
The client class name attribute.
The customer name attribute 1234 contains the value "Maria".
In general there is no distinction between property, attribute, characteristic or quality, unless it is an arbitrary or specific definition.
Examples:
The important thing here is to understand that distinctions are arbitrary and not part of the essence of the term property.
This discussion reminds me of the question Definitions of method, function and procedure?
Similarly, both have semantic differences that vary according to the context, but in practice are the same thing, whether referring to a group of instructions (routine, method, function) or a memory space associated with a structure (attribute, field, property).
When we talk about estates, qualities, attributes or characteristics of a chemical element, we refer to what is common to the whole set of existing matter of that element. We can also speak of the estates, qualities, attributes or characteristics common to all domestic cats.
On the other hand, if we speak of a specific entity, such as the chair you sit down to work or the cat Félix, then we will have specific values for your estates, qualities, attributes or characteristics.
This is an analogy between class and object/instance.
With all this, my argument is that it doesn’t make much sense to make a strong distinction between field, property and attribute, thus forcing a mental gymnastics every time we are confronted with the terms.
It makes more sense to draw a dividing line definition and value. It is much simpler to refer to one or the other like this:
That way the sense is clear using any of the terms.
3
Depending on the programming language, there is no distinction between attributes, properties and fields. Usually always called as fields or attributes.
It’s usually called estates fields that are available through access methods (getters and setters). But as stated earlier, there is no exact definition.
It does not change by language, Modeling is something that is part of a process, so processes are well defined. In a class diagram, attributes will always be attributes. Because this feature is part of the modeling process. Just as operations will always be operations and not methods. As long as it is part of the Modeling Process. Usually we take dialects of other aerial software construction and use as we want and in that confusion.
2
In object orientation we have the concept of Attributes, which are the characteristics that the class can have. When analyzing the literature (books, articles, scientific journals) we do not find the concept of field or property related to object orientation. About the properties, when we use java swing, Vb.net, Delphi or some language that allows the use of components, we say that these components have properties that can be modified to dye a certain goal. In practice, these properties are attributes, If we think in fields, in databases we can say that we have columns or fields and if we take a form in VB and Java Swing, we can say that the text boxes are fields, that in fact, if we program correctly in the object-oriented paradigm, they will be attributes of some class. To conclude, the correct is to use the Attribute nomenclature, since a class is composed of attributes and methods.
2
The impression I have is that in the diffusion of object-oriented programming several terms have been introduced in the literature and in the daily life of those who work in the area of programming, some of them have become ambiguous and others have tried to make something even more generic. Some of these terms may have been brought by those who came from other IT sectors, for example the term "field", may have been adopted by professionals with more database experience. But it’s all just an assumption of mine in an attempt to justify the controversy.
Variables:
Attribute:
Field:
Estate:
The Wikipedia article in English, which I and most sensible people consider much better, says something quite different from the Portuguese entry, which is famous for containing many errors and "owners" of entries that are not correct. The first statement of this section of the answer belies the second, or vice versa.
Local variables have nothing to do with OOP, I don’t know what this does here, maybe I wanted to ask about it, but it’s not in the question. And so we can say that every field is a variable, unless you consider a constant as a field, which I don’t know yet, and then it could only be of the class, it can’t have constants in instances. A field cannot be a member of an instance? What do you call the same thing as *getters and setters?
According to the last section, would this field be property? And what do you call the method(s) of get/set? What about their set? Could you talk more about the stricter control that properties should have? Take your time, reply to comments or edit the reply when you can.
The first statement does not contradict the second, it only says that a variable has no obligation to "vary" to be recognised as a variable, that is, it can be a constant. The variation is in memory allocation, which is done randomly, with no fixed address.
It is that it says that they are of class or instance, then only speaks in class. Memory allocation? Random? I do not fully understand what this means in this context.
Yes, during the execution of the application, its variables are temporarily allocated in RAM. Variable "x" receives a different address (i.e., variable) for each new application execution.
This doesn’t make any sense to me, but leave it alone because it’s not in the answer, and it doesn’t have to do with the question either, the other points are more important.
All right, my answer went bad, I agree. But it reflects what I see out there, basically field, attribute and class member, are treated as being the same thing. And maybe they are. The variables, on the other hand, depend on the paradigm we are talking about. In OOP, field, attribute and class member are also variables. The only detail that changes a little in the definition are the so-called "properties", which are private fields accessed by get/set methods.
That’s why I’m asking, I want her to help everyone who is having doubts about this, and I thought that hurt those points I quoted above as still normal doubt of most people.
When seeing me if you try to explain will always have a mixture of concept of language and process, First came the paradigm Orientation to object, with the need for standardization the documentations, along with that UML, hears a mixture of concept.
Good to prove this is to take ancient literature from Smaltalk, variables are variables and we have pseudo variables. But doesn’t Smaltalk use the object-oriented paradigm? In the analysis, Class attribute is the quality of class? Are not my class’s property attributes? If all this had been created together it would have been easier, UML 1994, Smaltalk 1969 and Simula.
0
In general, an object is able to carry values with it, which define its state, and distinguish them from other objects of the same type. That’s the only definition that matters.
These values that objects can load are referenced in several ways in the literature: attributes, properties, fields, variables, arguments, etc.
Some languages, including, provide different interpretations for each one, in order to provide functionality to developers and facilitate use, but the purpose is always to allow the object to carry values.
In practice, discussing the difference between them is as productive as functionally differentiating methods, functions and procedures. Equal to arguing that a function that does not return a value is not a function, or that an identified constant is not a variable.
Well, I find it fundamental and very productive to differentiate methods of functions, because the concept that separates them is trivial for any professional who wants to know what they are doing.
I have no doubt that separating concepts has their purpose, but I think this kind of reflection fits in a few places (it’s like comparing Java with Smalltalk to say that Java is not object oriented). Methods are different from functions conceptually, but both remain a block of code that we want to reuse for some reason. It’s hard to imagine a situation where changing terms can lead to a serious misunderstanding. The same goes for attributes vs. fields.
Browser other questions tagged oop terminology property attributes fields
You are not signed in. Login or sign up in order to post.
You have no idea how long I’ve waited for this question.
– Maniero