none
How can "Properties" exchange data (getters and setters) RRS feed

  • Question

  • I'm super confused about Properties (getters and setters), particularly predefined getters and setters.

    If I wanted to define the stroke of a rectangle to Violet, I could do this:

    Rectangle myRect = new Rectangle();
    myRect.Stroke = Brushes.Violet

    So from my understanding I am "getting" the property called Violet, and then "setting" the property of Stroke to that value of violet.
    Intellisense tells me that Stroke is of type Brush, and Violet is of type SolidColorBrush.

    My question is: How do you know what properties can exchange information with other properties? 
    I would have assumed that they would have to be of the same type, but if one is of type "Brush" and 
    the other is of type "SolidColorBrush", then this can't be true.

    For example I can't do this:

    Rectangle myRect = new Rectangle();
    myRect.Stroke =  BitmapPalettes.BlackAndWhite;

    If I do this, there is a compilation error ("Cannot implicitly convert type 'System.Windows.Media.Imaging.BitmapPalettes' to System.Windows.Media.Brush' ").


    Monday, July 14, 2014 11:04 AM

Answers

  • Object Browser is not the best way to get this information because it doesn't provide an easy way to find all types that derive from some base type.  Unfortunately only experience with the framework will really help you here.  What you can do is use the MSDN documentation to find out what you want to know. For example since you wanted a Brush you could look at the documentation for Brush. Often it will show you some of the core types that derive from it (especially for abstract types) and the See Also sections also tends to provide suggestions.  For example if you wanted a brush with color Violet then you know about the Brush type and that there is a Colors enum that has the colors.  From that you can look at the Brush documentation (or even Intellisense) to see if there is a constructor (ctor) that accepts a Color.  If you don't find one then switch to Color and see if there are any references.  If you're using Intellisense then as soon as you typed Brush you'd likely see Brushes.  In most of the framework pluralized type names are generally collections of base types.  For example Brushes contains a common set of Brush instances.

    If you're looking for inheritance examples then .NET is loaded with them but inheritance is just one pattern that is used in OOP.  Contracts (via interfaces) are becoming more prevalent than inheritance.  Inheritance has its limits (especially in C#).  Interfaces allow us to build up complex apps without relying on implementation details.  But interfaces strongly decouple the app from the implementation making discovery harder.  After you get a handle on inheritance you'll want to read up on using interfaces as contracts.

    Michael Taylor
    http://msmvps.com/blogs/p3net

    Tuesday, July 15, 2014 2:26 PM
    Moderator

All replies

  • A property is nothing more than syntactical sugar around a method call.  Properties are used to represent the read and/or writable attributes of a type (i.e. length and width of a rectangle).  Choosing between a property and a method is part of good class design and is partially covered in MSDN.  Some general rules are:

    • Properties should represent the attributes of an instance
    • Getting the value of a property should have no side effect such that calling a getter multiple times doesn't change any behavior.
    • Properties should be inexpensive to call (exception being lazy initialization, if appropriate).
    • Getting property values should generally not throw exceptions if a default value can be used instead
    • Properties can be get only if they represent attributes that cannot be changed directly (i.e. the area of a  rectangle)

    The discussion around Brush vs SolidColorBrush has nothing to do with properties but rather standard OOP.  SolidColorBrush derives from Brush and therefore inheritance comes into play.  Any place a Brush is used, a SCB (or any other derived type) can be used in its place.  It doesn't matter whether it is a property, field, local variable or parameter to a method.  In general properties are exposed using the most base type that the class needs but any derived type can be used.  In your example though you're trying to assign Stroke (of type Brush) a value that is of type BitmapPalette.  BP does not derive from Brush and therefore can not be used for it.

    Michael Taylor
    http://msmvps.com/blogs/p3net

    • Marked as answer by Raybust Monday, July 14, 2014 3:27 PM
    • Unmarked as answer by Raybust Monday, July 14, 2014 3:46 PM
    Monday, July 14, 2014 2:30 PM
    Moderator
  • I think I get what you're saying. If I look at the Object Browser in Visual Studio, the derived types of Brush are BitmapCacheBrush, GradientBrush, SolidColorBrush and TileBrush. This is why I can set my Stroke property (of type Brush) to a type of SolidColorBrush (Brushes.Violet)

    My next question is, what is the relationship between "Brushes" in Brushes.Violet and SolidColorBrush (the property type of Violet)? Is that another sort of OOP concept? 



    • Edited by Raybust Monday, July 14, 2014 3:30 PM
    Monday, July 14, 2014 3:27 PM
  • Many times you'll want to create a solid color brush (say, Violet).  To do that you'd do something like this:

    var brush = new SolidColorBrush(Color.Violet);

    You've just allocated an object to represent the violet brush.  Now imagine you want to use that color everywhere.  You can either reuse the brush by storing it as a field or creating new instances each time (not efficient).  Because this is so common the Brushes type provides SolidColorBrush instances of commonly used colors to save you the hassle.  So instead of writing the above code you can do this:

    var brush = Brushes.Violet;

    You basically get the same thing in both cases with a small caveat.  Brushes is internally creating an instance of the brush the first time it is needed.  All calls to the property after that will return the same instance.  This eliminates the extra allocations that would otherwise occur and is slightly faster. 

    However since all callers in the process get the same instance they are sharing the same brush.  The brush exposes some settable properties which means if one caller sets a property then the others would see that change, not generally desirable.  As such the returned brush is frozen (a WPF thing) so that any changes to the property values will fail at runtime.  If you were to need to tweak the brush then creating a new instance is still the correct approach.

    Michael Taylor
    http://msmvps.com/blogs/p3net

    Monday, July 14, 2014 5:15 PM
    Moderator
  • Thanks, this information was truly helpful! 

    I've asked these questions for a particular reason. I've been trying to explore the .net framework documentation of the class libraries. I'm in my second year at University and I understand most of the key concepts. If you look anywhere on the net that explains Object Orientated Programming, they'll give you some sort of Class Diagram/UML that depicts...I dont know...Lets say a Vehicle and a car. The'll say a car "is-a" vehicle and so inheritance is in play.

    However, this is all theory. I've been looking at the Object Browser in VS for some REAL examples of inheritance and OOP. More specifically, what I'm trying to find is Spontaneous Programming; such that, to achieve a certain outcome (eg Recording sound, etc)

    1. you search for a particular class.

    2. If class is abstract/interface etc, do this or do that to achieve desirable functionality.

    However, searching is a pain (and not everybody on the net has answers you are looking for).

    So when I asked about "properties exchanging data" I was looking specifically at the Object Browser. How are you supposed to know in the Object Browser what information can correlate with other information? For example;

    myRect.Stroke = Brushes.Violet

     how do you know you can set Stroke to Brushes.Violet? Where in the Object Browser does it say? Looking at the "base" or "derived" types is confusing and not always helpful. Or do I need some sort of other tool? 


    • Edited by Raybust Tuesday, July 15, 2014 3:14 AM
    Tuesday, July 15, 2014 3:13 AM
  • Object Browser is not the best way to get this information because it doesn't provide an easy way to find all types that derive from some base type.  Unfortunately only experience with the framework will really help you here.  What you can do is use the MSDN documentation to find out what you want to know. For example since you wanted a Brush you could look at the documentation for Brush. Often it will show you some of the core types that derive from it (especially for abstract types) and the See Also sections also tends to provide suggestions.  For example if you wanted a brush with color Violet then you know about the Brush type and that there is a Colors enum that has the colors.  From that you can look at the Brush documentation (or even Intellisense) to see if there is a constructor (ctor) that accepts a Color.  If you don't find one then switch to Color and see if there are any references.  If you're using Intellisense then as soon as you typed Brush you'd likely see Brushes.  In most of the framework pluralized type names are generally collections of base types.  For example Brushes contains a common set of Brush instances.

    If you're looking for inheritance examples then .NET is loaded with them but inheritance is just one pattern that is used in OOP.  Contracts (via interfaces) are becoming more prevalent than inheritance.  Inheritance has its limits (especially in C#).  Interfaces allow us to build up complex apps without relying on implementation details.  But interfaces strongly decouple the app from the implementation making discovery harder.  After you get a handle on inheritance you'll want to read up on using interfaces as contracts.

    Michael Taylor
    http://msmvps.com/blogs/p3net

    Tuesday, July 15, 2014 2:26 PM
    Moderator