c
I am trying to decode a piece of code from a book:
List<Person> people = new List<Person>()
{
new Person {FirstName="Homer",LastName="Simpson",Age=47},
new Person {FirstName="Marge",LastName="Simpson",Age=45}
};
Person is just a simple class they made, with a bunch of fields: Name, Last Name, etc…
What I don't understand is, don't we send parameters to a constructor of Person in non-curly brackets? I tried replicating this code, but it doesn't seem to fly, any takers?
Thanks for input.
What you are showing is programming with heavy side effects, which has the risk to lead to unmaintainable code, because it depends heavily on the correct order of execution, and the signatures of the Do... methods don't provide any information about their input and output. Here is an alternative design:
public class MyFooBarClass
{
public MyFooBarClass(string initialVal)
{
InitalValue=initialVal;
}
public readonly string InitalValue;
public string A { get { return InitalValue + "ob";}}
public string B { get {return "ar"; }}
public string FinalAnswer { get{return A+B;} }
}
Now, the order of execution is always correct, you can access the properties A ,B or FinalAnswer in any order you like, the object has become immutable, which makes it more robust against changes or multithreading. Of course, when you call FinalAnswer multiple times, the same calculation will be repeated again, so if your notice a (measurable!) loss of performance, you may have to introduce memoizing techniques (but I would avoid any premature optimization if there is no real reason for this).
Another design alternative, if you really need to separate the result object from the calculation class:
public static class foobar
{
public static Result DoStuff(string initialVal)
{
string a = DoSomething_A(initialVal);
string b = DoSomething_B();
string finalAnswer = A + B;
return new Result(initialVal,a,b,finalAnswer);
}
private static string DoSomething_A(string initialVal)
{
return initialVal + "ob";
}
private static string DoSomething_B()
{
return "ar";
}
}
public class Result
{
public Result(string initalValue, string a, string b, string finalAnswer)
{
InitalValue=initalValue;
A=a;
B=b;
FinalAnswer=finalAnswer;
}
public readonly string InitalValue;
public readonly string A;
public readonly string B;
public readonly string FinalAnswer;
}
This makes the data flow much more expressive, you now see immediately what each of the Do methods uses as input, what it returns as output, and the result object is still immutable.
The calling code which instantiated a FooRepository object is passing an IDbConnection object and therefore has the right to access this information later on
This is not true when you're dealing with things like the factory pattern, where the instantiator of the object is not the handler of the object. Factory patterns quite often exist specifically because the object's construction is an implementation detail that should be abstracted away.
This applies to more cases than just the factory pattern. Essentially, it applies to any object that gets passed around at least once.
but can't modify it anymore (no set on the DbConnection property)
This isn't true for reference types. It's true that you can't change which object is being referenced, but you can still alter its content. For example:
public class Foo
{
public string Name { get; set; }
}
public class Baz
{
public Foo Foo { get; } // allegedly: "can't modify it anymore"
public Baz(Foo foo)
{
this.Foo = foo;
}
}
var myFoo = new Foo() { Name = "Hello" };
var myBaz = new Baz(myFoo);
As per your claim, myBaz.Foo can no longer be modified. Yet this code is perfectly legal:
myBaz.Foo.Name = "a completely different name";
And that's still a risk you take.
he told me that any class I write, it should expose just the minimum useful information.
I don't want to think few minutes for each parameter to determine if this would be a good idea to expose it or not.
These two don't quite follow. It doesn't require you to think about it, it requires you to default to private instead of public like you currently do. Unless there is a valid reason to expose it, don't.
This is an oversimplification as there are cases where you shouldn't start out on private (e.g. DTO properties), but if you're still struggling with evaluating this, it's already better to default to private instead of public.
In my opinion, there are some use cases we simply can't think of when we first write a new class.
In my opinion, this is indicative of not quite understanding the class' responsibility and how it fits in the existing codebase.
In fact, that's sort of what you state in the question: you don't want to think about it. But you really should. For your example, what would ever be the purpose of a repository exposing its database connection? I can't think of any answer here that does not immediately violate good practice rules, can you?
Exposing the database connection is not part of the repository's purpose, which is all about providing access to a persistent data store.
In part, this is a matter of experience which will come over time. Every time you have to change the access modifier on an existing property/method is a time to learn why the previous choice was not the right one. Do it enough and you will improve at judging public contracts on the first design.
In my opinion, there are some use cases we simply can't think of when we first write a new class.
Don't forget OCP: "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification".
If you are inherently accounting for needing to change the internals of classes as time passes, you're taking a stance orthogonal to OCP.
That's not to say internals can't be changed when e.g. bugs are found or breaking changes are implemented; but it does mean you should try to avoid it as best as you can. Changing existing (often central) logic is a most common source of bugs, especially the crippling ones.
Whether or not the class will finally be included in a Nuget package doesn't really matter.
It really does matter. If your library is only being used in the same solution file, you can change things very quickly to your needs and can confirm it's working with a simple build.
But Nuget compounds the issue. If you change the contracts of your classes exposed in yout Nuget package, that means that every Nuget consumer will have to deal with breaking changes.
From personal experience, the issue is further compounded by Nuget servers not keeping a record of who has consumed your Nuget package, which makes it hard to figure out who all your consumers are and warn them ahead of time that breaking changes are about to be released.
Had you defaulted to making things private, and then selectively expose them, there would be less of a problem here. Adding to the contract without changing the existing parts does not break existing code.
Removing things from the contract, which is what would happen if you default to public, would always be liable to breaking code that depends on the thing you're now removing from the contract.
Should I really think for each parameter if it makes sense to expose it?
Yes. But it's not as complicated as you're making it out to be. Understanding what a certain class needs to expose or not is something you need to think about once per class. What is this class' purpose? How do I want this class to be used by its consumers?
After that, all properties/methods that you develop can easily be matched to the class' purpose, which is not a new evaluation but simply applying the decision you already made.
Or is there a design pattern I can just instinctively apply without wasting too much time?
If you were using interfaces on all your classes and using interface-based dependency injection, it would really help you in understanding how to separate a class' contract (things in the interface) from its implementation (things not in the interface).
Take for example:
public interface ISodaVendingMachine
{
Soda GetDrink();
}
public class RegularVendingMachine : ISodaVendingMachine
{
private Drinks drinks;
public RegularVendingMachine(Drinks drinks)
{
this.drinks = drinks;
}
public Soda GetDrink()
{
return this.drinks.TakeOne();
}
}
public class ConjuringVendingMachine : ISodaVendingMachine
{
private PhilosophersStone philosophersStone;
public ConjuringVendingMachine(PhilosophersStone philosophersStone)
{
this.philosophersStone = philosophersStone;
}
public Soda GetDrink()
{
return philosophersStone.PerformIncantation("Drinkum givum");
}
}
The internals of each vending machine is up to them. It doesn't matter how they have access to and dispense a drink to the consumer. To the consumer, that's an irrelevant implementation detail. The customer doesn't want to know how the sausage gets made.
What matters for the public contracts is that they dispense a drink to the consumer, and thus the ISodaVendingMachine interface is built specifically for that purpose.
Notice how the interface doesn't care about anothing other than what it was designed to ensure.
When you have that interface, you can already see that anything in your class that isn't part of that interface should most likely be private as it is an implementation detail, not a contract.
Best Answer
C# allows you to specify property parameters in curly braces when the object is initialized. This allows you to pick and choose which items to initialize and which to leave as defaults.
A constructor, on the other hand, runs one single block of code with a fixed set of parameters. So to get the same effect you'd have to create multiple constructors all with the various combinations of properties you might want to initialize, which could be tedious.
is exactly equivalent to this:
Except that it's shorter and arguably easier on the eyes.
It also allows for constructs like you demonstrated in your question, which would be very tedious if you had to create temporary variables and initialize them out as I did here before adding them to the list. (Which is how you used to have to do it.) All without requiring an explicitly-defined constructor that takes your desired list of parameters, which may or may not be available.
Also, note that while a constructor can initialize properties with a private setter, this technique (as should be obvious from the provided example) will only work if you have a public setter for the property. Also note that my shortened example implicitly called the default (parameterless) constructor, which would therefore have to be present.