Pergunta

Maybe it's a so simple question or impossible to do that. I don't know i'm just asking.

i have a class like this :

    namespace Perimeter_Distance
{
    class Station
    {
        public string Name { get; set; }
        public decimal Lng { get; set; }
        public decimal Lat { get; set; }
    }
}

i'm populating class in the mainwindow on wpf :

public partial class MainWindow : Window
    {
        // initializing class with definitions
        List<Station> stations = new List<Station>()
            {   new Station {Name = "01 -- Söğütlüçeşme -- 45",Lat=40.994864M,Lng=29.037337M},
                new Station {Name = "02 -- Fikirtepe -- 44",Lat=40.993824M,Lng=29.047972M},
                new Station {Name = "03 -- Uzunçayır -- 43",Lat=40.998778M, Lng=29.056474M}
            };

My question is am i doing right or can we populate/initialize class in a constructor.

I want all of my voids can access to class in the wpf.

I'm sorry my english is not good enough but i hope i wrote down the problem correctly.

Foi útil?

Solução

What you're doing is fine, however, if you provide a constructor for Station, not only will your calling code be more clean, but the calling code won't need to decide what should be hydrated within the entity. The information expert principle states that the class with the most knowledge of how to do something should be the one to do it. That would mean adding a constructor that takes three arguments: Name, Lng, Lat.

class Station
{
    public string Name { get; set; }
    public decimal Lng { get; set; }
    public decimal Lat { get; set; }

    public Station(string name, decimal longitude, decimal latitude)
    {
        this.Name = name;
        this.Lng = longitude;
        this.Lat = latitude;
    }
}

Now your calling code won't need to decide what should be sent to create a valid object. It can just do this:

var station = new Station("01 -- Söğütlüçeşme -- 45", 40, 29);

If a station isn't valid unless it has all three properties, adding the constructor can help enforce valid objects being created.

I'd also recommend not abbreviating your property names for future maintainability.

Edit

If your question is really about adding data in the UI:

You should be getting your data from your business logic, not in the main window of a UI. And you should not have to type this data in code; it should exist in some kind of persistence store (DB, file, etc.). See stackoverflow.com/a/13790722/279516

Outras dicas

The initialization which you show Object Initialization is the best for when the class has a lot of properties which need to be assigned or one has a process (think Entity Framework) where an instance may be initialized via reflection and providing a constructor for such a scenario would be more work than using the default constructor and using object initialization.

I prefer object initialization that you have over a constructor because with lots of POCO objects its time consuming to create constructors which frankly don't have to be created. Otherwise to use a constructor for arguments more than 3+ conflicts with some peoples' rule to not have multiple argument methods/constructors. So one can get into a back and forth war over its usage.

Also mixing up similar values, in your example the decimals, is less likely to happen under Object Initialization.

Just remember that the property assignment during instance creation happens after construction. So any property set in the constructor will lose value after the property is set outside. That is important if one is practicing Dependency Injection where an internal property will be overridden by an assignment to a property by an outside operation (think test). That allows for an operation (as property) to occur to be setup during construction to be safely overridden if necessary later for test purposes.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top