We Keep Coding

How do get set methods stop dependencies?

So I understand that if we want to change the implementation detail of a class, using those details outside of the class will cause errors when things are changed, this is why we set those fields to private. However, if we use get set methods with a private field doesn't this do the same thing? If I decided I didn't want my class to have a name and a username, just a name, and I delete the private username field, the get / set methods will break with that and it will cause the places where those methods are used to also break. Isn't referencing one class a dependency no matter what in case we change that classes methods or fields? What is the point of Get Set methods then and how do they stop code from breaking like this?

However, if we use get set methods with a private field doesn't this do the same thing?
Yes. Arguably, yes. The original idea of Object Oriented Programming, as Alan Kay -who coined the term- initially thought about it, has been distorted. Alan Kay has expressed his dislike for setters:
Lots of so called object oriented languages have setters and when you have a setter on an object you turned it back into a data structure.
-- Alan Kay - Programming and Scaling (video).
Isn't referencing one class a dependency no matter what in case we change that classes methods or fields?
Correct. If you are referencing a class from another, your classes are tightly coupled. In that case a change of one class will propagate to the other. Regardless if the change is in public fields, getter, setters or something else.
If you are using an interface or similar indirection, they are loosely coupled. This looseness gives you an opportunity to stop the propagation of the change. Which you may or may not do.
Finally, if you are using an observer pattern or similar (e.g. events or listeners), you can have classes decoupled. This is, in a way, retrofitting the idea of passing messages as originally conceived by Alan Kay.
What is the point of Get Set methods then and how do they stop code from breaking like this?
They allow you to change the internal representation of the class. While the common approach is to have setters and getters correspond to a field, that does not have to be the case. A getter might return a constant, or compute a value form multiple fields. Similarly, a setter might update multiple fields (or even do nothing).
Reasons to have setters:
They give you an opportunity to implement validations.
They give you an opportunity to raise "changed" events.
They might be necessary to work with other systems (e.g. some Dependency Injection frameworks, also some User Interface frameworks).
You need to update multiple fields to keep an invariant. Presumably updating those other fields don't result in some public property changing value in an unexpected way (also don't break single responsibility principle, but that should be obvious). See Principle of least astonishment.
Reasons of getters:
They give you an opportunity to implement lazy initialization.
They give you an opportunity to return computed values.
They might make debugging easier. Consider some getters for DEBUG builds only.
If you had public fields, and then you decided you needed anything like what I described above, you may want to change to getters and setters. Plus, that change require to recompile the code that uses it (even if the source is the same, which would be the case with C# properties). Which is a reason it is advised to do it preemptively, in particular in code libraries (so that an application that uses it does not have to be recompiled if the library changed to a newer version that needed these changes).
These are reasons to not have getters: Often, getters exist to access a member to call method on it, which leads to very awkward interfaces (see Law of Demeter). Or to take a decision, which may lead to a Time-of-check to time-of-use bug, which also means the interface is not thread-safe ready. Or to do a computation, which is often better if the class has a method to do it itself (Tell, Don't Ask).
And for setters, aside for being a code smell of bad encapsulation, could be indicative of an unintended state machine. If code needs to call a setter (change the state), to make sure it has the intended value before calling a method, just make it a parameter (yes, even if you are going to repeat that parameter in a lot of methods). Such interface is easy to misuse, plus is not thread-safe ready. In general, avoid any interface design in which the code using it has to call things in an order that it does not forces you to (a good design will not let you call things in an order that results in an invalid state (see poka-yoke). Of course, not every contract can be expressed in the interface, we have exceptions for the rest.).
A thread-safe ready interface, is one that can be implemented in a thread-safe fashion. If an interface is not thread-safe ready, the only way to avoid threading problems while using it is to wrap access to it with locks external to it, regardless of how the interface is implemented. Often because the interface prevents consolidating reads and writes leading to a Time-of-check to time-of-use bug or an ABA problem.
There is value in public fields, when appropriate, too. In particular for performance, and for interoperability with native code. You will find, for example, that Vector types used in game development libraries often have public fields for its coordinates.
As you can see, there can be good reasons for both having and not having getters and setters. Similarly, there can be good reasons for both having or not having public fields. Plus, either case can be problematic if not used appropriately.
We have guidelines and "best practices" to avoid the pitfalls. Not having public fields is a very good default. And not every field needs getters and setters. However, you can make getters and setters, and you can make fields public. Do that if you have a good reason to do it.
If you make every field public you will likely run into trouble, braking encapsulation. If you make getters and setters for each and every field, it is not much better. Use them thoughtfully.

Why can I call this static method using the class name but not using a class instance?

class Program
{
static void Main(string[] args)
{
var p = new Program();
p.Main(args);//instance reference error,use type name instead
var p = new Program();
Program.Main(args);//error disappears
}
}
I think I understand that statics are not associated with object instances, but what I'm having trouble with is aren't classes synonymous with objects? Or aren't classes used in creating objects? So why does the error disappear when I use the class name if classes are essentially objects?
I get that I haven't yet created an instance of Main and won't be. Is that the only thing that makes the difference? Maybe it's just not being explained properly in this class I'm taking.

Your confusion is a very natural one, and it is exacerbated by the design of C# in this respect. I'll try to explain as we go, and I'll reformulate your questions to be easier to answer:
Is class synonymous with object?
No. Let's be very, very clear on this point. "Object" has a specific meaning in C#. An object is always an instance of a type. There are two broad kinds of object in C#: reference types which are copied by reference, like string and value types which are copied by value, like int.
Later you will learn about boxing, which is the mechanism by which an instance of value type may be used in a context that expects a reference, but don't worry about that for now.
In C# a class defines a reference type. Instances of that class are objects. The class itself is not an object.
The justification for this comes from the real world. The class "all objects which are newspapers" is not itself a newspaper. The class "all people who speak French" is not itself a French speaker. It is a category error to confuse a description of a set of things with a specific example of the thing!
(You may wish to examine closely the design of prototype inheritance languages such as JavaScript. In JS we make a specific object that is the prototypical example of a kind of thing, and we make a constructor object that represents the factory for new examples of that kind of thing; the prototype and the constructor work together to make new instances, and both are genuinely objects. But again, your question is about C#, so let's stick to that for now.)
are classes used in creating objects?
Yes. We instantiate a class with new; since all classes are reference types, new produces a reference to a novel object.
So why does the error disappear when i use the class name, if classes are essentially objects?
Classes are not objects, but I understand your confusion. It certainly looks like the class name is being used in a context where you would expect an object. (You might be interested to examine closely the design of languages like Python where classes are objects, but your question is about C# so let's stick to that.)
To resolve this confusion you need to understand that the member access operator, also called the "dot operator", in C# is one of the most flexible and sophisticated operators. This makes it easy to use but hard to understand!
The key thing to understand is that the member access operator always has this form:
On the left of the dot is an expression that evaluates to a thing that has members
On the right of the dot is a simple name.
Though it is possible, and common, for thing to be an object and thing.name to be an object, it is also possible for either or both to not be an object.
When you say p.Main the compiler says "I know that p is an instance of Program, and I know that Main is a name. Does that make sense?"
The first thing the compiler does is verifies that Program -- p's type -- has an accessible member Main, which it does. At this point overload resolution takes over, and we discover that the only possible meaning of Main is a static method. This is likely a mistake because p is an instance, and we're attempting to invoke a static through the instance. C#'s designers could have allowed this -- it is allowed in other languages. But since this is a likely mistake, they disallowed it.
When you type Program.Main, Program is not an object. The compiler verifies that Program refers to a type and types have members. Once again, overload resolution takes over and it determines that the only possible meaning is that Main is being invoked. Since Main is static and the receiver -- the thing on the left of the dot -- refers to a type, this is allowed.
Maybe it's just not being explained properly in this class I'm taking.
I edit technical books and other course materials and a great many of them explain these concepts very poorly. Also a great many instructors have vague and confused notions about the relationships between classes, objects, variables, and so on. I encourage you to question your instructor closely on these matters until you are satisfied with their explanations.
That said, once you have a solid grasp on these matters then you can start to take shortcuts. As expert C# programmers we say "p is an object which..." because we all know that we mean "p is a variable, the value of which is a reference to an object which..."
I think it is helpful for the beginner to spell it out, but you will very quickly become more relaxed about it.
One other thing that you did not ask but is important:
What about reflection?
.NET has a reflection system which allows you to take things that are not objects, like classes, structs, interfaces, methods, properties, events, and so on, and obtain an object which describes them. (The analogy being that a mirror image is not reality but it sure looks like it enough to understand reality.)
It is important to remember that the reflection object is not the class. It is an object which describes the class. If you use reflection in your program like this:
Type t = typeof(Program);
then the value of t is a reference to the Type object that describes the characteristics of class Program. You could inspect that object and determine that there was a MethodInfo for method Main, and so on. But the object is not the class. You cannot say
t.Main();
for example. There are ways to invoke methods via reflection, but it is a mistake to think of the Type object as being the class. It reflects the class.
Another question you did not ask but is germane to your education:
What you're saying here is that values are instances of objects, but certain programming language constructs such as classes are not objects that can be manipulated like values. Why is it that some programming language constructs in C# are "first class" -- they can be treated as data manipulated by the program -- and some are "second class", and cannot be so manipulated?
That question gets to the crux of language design itself. All language design is a process of examining past languages, observing their strengths and weaknesses, coming up with principles that attempt to build on strengths while mitigating weaknesses, and then resolving the countless contradictions entailed when principles come into conflict with each other.
We all want a camera that is lightweight, inexpensive, and takes great pictures, but as the saying goes, you can only have two. The designers of C# were in a similar position:
We want languages to have a small number of concepts that must be understood by the novice. Moreover, we achieve this by unifying disparate concepts into hierarchies; structs, classes, interfaces, delegates and enums are all types. if, while, foreach are all statements. And so on.
We want to be able to build programs that manipulate values that are important to the developer in powerful ways. Making functions "first class" for example opens up powerful new ways to program.
We want programs to have little enough redundancy that developers do not feel like they are forced into unnecessary ceremony, but sufficient redundancy that humans can understand the program as written.
And now the big ones:
We want the language to be general enough to allow line-of-business developers to write programs that represent any concept in their business domain
We want the language to be understandable by machines to the extent that the machines can find likely problems before the program even runs. That is, the language must be statically analyzable.
But like the camera, you can't have all of these at once. C# is a general-purpose programming language designed for programming in the large with a strong static type checker for finding real-world mistakes before they make it into production. It is precisely because we want to find the sort of error you're encountering that we do not allow types to be treated as first-class values. If you treat types as first class then huge amounts of static analysis capability goes out the window!
Other language designers made completely different choices; the consequences of Python saying "classes are a kind of function, and functions are a kind of object" dramatically moves the language towards our desired goal of hierarchical simplicity and first-class treatment of language concepts, and dramatically away from ability to statically determine correctness. That's the right choice for Python, but not for C#.

Static methods in classes are meant to be connected to the class. Other methods are meant to be connected to objects. This way, you can access static methods without having to create an object. In c++, this the boilerplate code you would use:
className::staticMethod();

Is it possible to make a third-party mutable struct "more immutable" via F#?

For example, wouldn't this type:
https://msdn.microsoft.com/en-us/library/microsoft.xna.framework.vector2.aspx
... having public mutable fields like this:
https://msdn.microsoft.com/en-us/library/microsoft.xna.framework.vector2.x.aspx
... single-handedly make consuming F# code's immutability efforts kind of useless?
PS: performance must be preserved, no wrapping or dynamic instantiation of throw-away values.
PPS: I did some research and suspect the answer (negative) but would appreciate some input. It seems like a typical problem when not implementing everything in F# from scratch.

For collections of structs, this is not an issue. The collection remains immutable irrespective of the struct's members, since getting the struct from the collection returns a copy. Altering this copy does not alter the collection's contents.
Elsewhere, structs can be used to write wrappers without additional GC load. This requires to create methods for all features you want to keep and have them call the original methods. Unless the JIT doesn't inline the calls, this shouldn't cost performance. However, when wrapping reference types, this will create an empty default constructor on the wrapper type, resulting in a null reference if this constructor is called.
As a side note, I wouldn't recommend using vector classes from outside F#, since they are not unit-of-measure aware. In my experience, most vectors can be assigned physical units, which makes code safer and more readable.

You are correct, the short answer is no. However, at least in the case of the Vector2 class you show, many of the operations are implemented in an immutable fashion when you use the static versions of the methods. For example
var vecB = Vector2.Normalize(vecA);
is an immutable call. Unless the libraries you are using support some kind of immutability, you are stuck with having to implement the immutable functionality you want to have.
F# has a design goal of being a hybrid of mutable and immutable content so that it can access the rich functionality of .NET libraries when needed.

Why is it good to use Properties instead of fields? [duplicate]

This question already has answers here:
What is the difference between a field and a property?
(33 answers)
Closed 9 years ago.
I read a lot on how I am never supposed to use fields in my models and DTOS but I dont ever read why this is.
public int property{ get; set; }
public int Foo;
under the hood that is the difference between theese two?

One important difference is that interfaces can have properties but not fields.
This article given by JON SKEET is very useful in understanding this.
Practical benefits of properties
There are times when you could use non-private fields, because for
whatever reason you don't care about the compatibility reasons above.
However, there are still benefits to using properties even for trivial
situations:
There's more fine-grained access control with properties. Need it to be publicly gettable but really only want it set with protected
access? No problem (from C# 2 onwards, at least).
Want to break into the debugger whenever the value changes? Just add a breakpoint in the setter.
Want to log all access? Just add logging to the getter.
Properties are used for data binding; fields aren't.

One good reason is because it allows you to incluede logic and verification inside of the getters and setters

Taken from: http://csharpindepth.com/Articles/Chapter8/PropertiesMatter.aspx
Practical benefits of properties
There are times when you could use non-private fields, because for whatever reason you don't care about the compatibility reasons above. However, there are still benefits to using properties even for trivial situations:
There's more fine-grained access control with properties. Need it to be publicly gettable but really only want it set with protected access? No problem (from C# 2 onwards, at least).
Want to break into the debugger whenever the value changes? Just add a breakpoint in the setter.
Want to log all access? Just add logging to the getter.
Properties are used for data binding; fields aren't.
None of these are traditional "adding real logic" uses of properties, but all are tricky/impossible with plain fields. You could do this on an "as and when I need it" basis, but why not just be consistent to start with? It's even more of a no-brainer with the automatic properties of C# 3.
The philosophical reason for only exposing properties
For every type you write, you should consider its interface to the rest of the world (including classes within the same assembly). This is its description of what it makes available, its outward persona. Implementation shouldn't be part of that description, any more than it absolutely has to be. (That's why I prefer composition to inheritance, where the choice makes sense - inheritance generally exposes or limits possible implementations.)
A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. A field, on the other hand, communicates the implementation - it says "this type represents a value in this very specific way". There's no encapsulation, it's the bare storage format. This is part of the reason fields aren't part of interfaces - they don't belong there, as they talk about how something is achieved rather than what is achieved.
I quite agree that a lot of the time, fields could actually be used with no issues in the lifetime of the application. It's just not clear beforehand which those times are, and it still violates the design principle of not exposing implementation.

Is it good practice to use reflection in your business logic?

I need to work on an application that consists of two major parts:
The business logic part with specific business classes (e.g. Book, Library, Author, ...)
A generic part that can show Books, Libraries, ... in data grids, map them to a database, ...).
The generic part uses reflection to get the data out of the business classes without the need to write specific data-grid or database logic in the business classes. This works fine and allows us to add new business classes (e.g. LibraryMember) without the need to adjust the data grid and database logic.
However, over the years, code was added to the business classes that also makes use of reflection to get things done in the business classes. E.g. if the Author of a Book is changed, observers are called to tell the Author itself that it should add this book to its collection of books written by him (Author.Books). In these observers, not only the instances are passed, but also information that is directly derived from the reflection (the FieldInfo is added to the observer call so that the caller knows that the field "Author" of the book is changed).
I can clearly see advantages in using reflection in these generic modules (like the data grid or database interface), but it seems to me that using reflection in the business classes is a bad idea. After all, shouldn't the application work without relying on reflection as much as possible? Or is the use of reflection the 'normal way of working' in the 21st century?
Is it good practice to use reflection in your business logic?
EDIT: Some clarification on the remark of Kirk:
Imagine that Author implements an observer on Book.
Book calls all its observers whenever some field of Book changes (like Title, Year, #Pages, Author, ...). The 'FieldInfo' of the changed field is passed in the observer.
The Author-observer then uses this FieldInfo to decide whether it is interested in this change. In this case, if FieldInfo is for the field Author of Book, the Author-Observer will update its own vector of Books.

The main danger with Reflection is that the flexibility can escalate into disorganized, unmaintainable code, particularly if more junior devs are used to make changes, who may not fully understand the Reflection code or are so enamored of it that they use it to solve every problem, even when simpler tools would suffice.
My observation has been that over-generalization leads to over-complication. It gets worse when the actual boundary cases turn out to not be accommodated by the generalized design, requiring hacks to fit in the new features on schedule, transmuting flexibility into complexity.

I avoid using reflection. Yes, it makes your program more flexible. But this flexibility comes at a high price: There is no compile-time checking of field names or types or whatever information you're collecting through reflection.
Like many things, it depends on what you're doing. If the nature of your logic is that you NEVER compare the field names (or whatever) found to a constant value, then using reflection is probably a good thing. But if you use reflection to find field names, and then loop through them searching for the fields named "Author" and "Title", you've just created a more-complex simulation of an object with two named fields. And what if you search for "Author" when the field is actually called "AuthorName", or you intend to search for "Author" and accidentally type "Auhtor"? Now you have errors that won't show up until runtime instead of being flagged at compile time.
With hard-coded field names, your IDE can tell you every place that a certain field is used. With reflection ... not so easy to tell. Maybe you can do a text search on the name, but if field names are passed around as variables, it can get very difficult.
I'm working on a system now where the original authors loved reflection and similar techniques. There are all sorts of places where they need to create an instance of a class and instead of just saying "new" and the class, they create a token that they look up in a table to get the class name. What does this gain? Yes, we could change the table to map that token to a different name. And this gains us ... what? When was the last time that you said, "Oh, every place that my program creates an instance of Customer, I want to change to create an instance of NewKindOfCustomer." If you have changes to a class, you change the class, not create a new class but keep the old one around for nostalgia.
To take a similar issue, I make a regular practice of building data entry screens on the fly by asking the database for a list of field names, types, and sizes, and then laying it out from there. This gives me the advantage of using the same program for all the simpler data entry screens -- just pass in the table name as a parameter -- and if a field is added or deleted, zero code change is required. But this only works as long as I don't care what the fields are. Once I start having validations or side effects specific to this screen, the system is more trouble than it's worth, and I'm better off to fall back to more explicit coding.

Based on your edit, it sounds like you are using reflection purely as a mechanism for identifying fields. This is as opposed to dynamic behavior such as looking up the fields, which should be avoided when possible (since such lookups usually use strings which ruin static type safety). Using FieldInfo to provide an identifier for a field is fairly harmless, though it does expose some internals (the info class) in a way that is not entirely ideal.

I tend not to use reflection where i can help it. by using interfaces and coding against these i can do a lot of things that some would use reflection for.
But im a big fan of if it works, it works.
Also by using reflection you probably have something that can adapt fairly easily.
Ie the only objection most would have is fairly religious ... and if your performance is fine and the code is maintainable and clear .... who cares?
Edit: based on your edit i would indeed use interfaces to achieve what you want. Unless i misunderstand you.

I think it is a good idea to stay away from Reflection when possible, but dont be afraid to resort to it when it provides a better or more flexible solution to your problem. The performance hit for anything but tight loop operations is likely to be minimal in the overall scheme of an application or Web Form request.
Just a good article to share about reflection -
http://www.simple-talk.com/dotnet/.net-framework/a-defense-of-reflection-in-.net/

I tend to use interfaces in my business layer and leave the reflection to my presentation layer. This is not an absolute but rather a guideline.