You are not using at the same time, you are doing a structure and then a class. No problem at all, at least not because there is both. But this case seems to be quite wrong.
The organization is right, but the most correct would be to have two * classes.
Why can not you use struct
in Endereço
?
There are two "impediments".
First it is too big. It will have 4 words (assuming it will not grow in the future). In 32-bit architecture there are 16 bytes. In 64-bit architecture there are 32 bytes. Only the pointers to the text are that they are stored in the structure.
That's a lot, it's up to the recommended limit, but it can grow, it does not have a zip code, you might need more things, like "add-on" or "location indication." Structures should only be up to 16 bytes. I've already done a few tests and I've seen good results with bigger sizes, but I know what I'm doing and when I want to go over the official recommendation, it has a lot of nuance, if I do not understand everything, it's best to stick to the recommendation.
The problem is that structures are types per value and they are passed by copy, it may be inefficient if it is very large.
Just because they are of value people do not fully understand semantics when they change their data.
When you copy the data of a variable by value ( struct
) another object is created, so moving one does not move the other. And there is a lot of copy that the person does not even notice that occurs. In cases of types by reference (% with%) the copy is of the pointer and not of the object itself, so it is always the same object. Moved on him, all references to him will see the modification. Marco Giovanni's response shows how this happens.
Structures must be immutable , or change everything and get a new object or not change nothing . It does not seem to be the case with class
. Data can be changed independently. In fact there is no mechanism protecting it.
Have you noticed the C # types that are Endereco
? Everything small and indivisible.
There are exceptions
If you know full well what you're doing, you can abuse the structures to gain performance by easing the garbage collector . This site you are using now does a lot of that in your software. In cases that need to avoid copying, it uses structs
. That alias, with new features in C # 7, will tend to be used more and more on systems where performance and memory management matter most.
The new features coming in the next versions will help ensure immutability, although you can do so now.
Again, everything can be understood as having implications for its use.
Note that some classes prefer to be immutable. ref
is the most obvious case. It must be said that everything should be immutable and this is done in other languages. It has its disadvantages.
To better understand read What is the difference between Struct and Class?
Eric Lippert talks in detail and few people have more authority over it than he. The example he puts in is great:
struct Mutable {
private int x;
public int Mutate() {
this.x = this.x + 1;
return this.x;
}
}
class Test {
public readonly Mutable m = new Mutable();
static void Main(string[] args) {
Test t = new Test();
System.Console.WriteLine(t.m.Mutate());
System.Console.WriteLine(t.m.Mutate());
System.Console.WriteLine(t.m.Mutate());
}
}
What does it do?
Prints 1, 2, 3 - because String
is m
, even though this applies only to the variable and not its members.
Prints 0, 0, 0 - because readonly
is m
, x can not be changed and always has default value 0.
It throws an exception when so much change the member state, which it believes to be readonly
(not declared, but thinks that is transferred from variable to member.
Prints 1, 1, 1. Because the data is copied to each access, it does not use the previous state. When you use readonly
, you get a copy of what's in t.m
. m
is immutable (by m
), but your copy is not.
There may be problems with this approach, even if you use a class, but I will not speak because it is not the focus of the question. You may also have other problems with your code. But there's no context, it's hard to say.
* Note that I have not even looked at whether the address should actually be a separate entity. This may be a mistake in your case. I can not judge that.