Child Objects Inheriting Property Values from Parents
-
I have a hierarchy of objects that share some attributes, e.g. both my parent Record and Column objects have a columnDelimiter property. I want this property on the Column object to default to the same property on the Record object, until specified on the Column object. What is the best way to go about this? I could give each Column a reference to the Record it belongs to, but this seems not quite right to me. My other option is to have the Record act as a ColumnFactory, setting the columnDelimiter value on each Column it creates, until a set accessor on Column optionally overrides that default value.
My head asplode!
Calling all South African developers! Your participation in this local dev community will be mutually beneficial, to you and us.
-
I have a hierarchy of objects that share some attributes, e.g. both my parent Record and Column objects have a columnDelimiter property. I want this property on the Column object to default to the same property on the Record object, until specified on the Column object. What is the best way to go about this? I could give each Column a reference to the Record it belongs to, but this seems not quite right to me. My other option is to have the Record act as a ColumnFactory, setting the columnDelimiter value on each Column it creates, until a set accessor on Column optionally overrides that default value.
My head asplode!
Calling all South African developers! Your participation in this local dev community will be mutually beneficial, to you and us.
-
I am having trouble understanding your problem. Can you provide a scenario where the column delimiter is different from the record delimiter?
No, maybe that was a bad example, but I'm trying to build in forward compatibility with SSIS, and their columns all define their own delimiters. However, my problem is not one of Column specified column delimiters and Record specified column delimiters; it is one of child objects 'inheriting' property values from their parents, until or unless the child object overrides the value. I do have exactly the same requirement for individual Columns to have an option to quote their contents, which overrides the 'quote contents' option for the Record.
My head asplode!
Calling all South African developers! Your participation in this local dev community will be mutually beneficial, to you and us.
-
No, maybe that was a bad example, but I'm trying to build in forward compatibility with SSIS, and their columns all define their own delimiters. However, my problem is not one of Column specified column delimiters and Record specified column delimiters; it is one of child objects 'inheriting' property values from their parents, until or unless the child object overrides the value. I do have exactly the same requirement for individual Columns to have an option to quote their contents, which overrides the 'quote contents' option for the Record.
My head asplode!
Calling all South African developers! Your participation in this local dev community will be mutually beneficial, to you and us.
Brady Kelly wrote:
I'm trying to build in forward compatibility with SSIS
I don't know what that means.
Brady Kelly wrote:
I do have exactly the same requirement for individual Columns to have an option to quote their contents, which overrides the 'quote contents' option for the Record.
Sorry, I just don't get it.
-
Brady Kelly wrote:
I'm trying to build in forward compatibility with SSIS
I don't know what that means.
Brady Kelly wrote:
I do have exactly the same requirement for individual Columns to have an option to quote their contents, which overrides the 'quote contents' option for the Record.
Sorry, I just don't get it.
OK, Record is my parent object (not base object), and it has a collection of child Column objects. Record has a boolean property, QualifyText, which when set, surrounds string columns with a configured qualifying character. Column, a child object, also has a QualifyText property. If this property is set on a Column object, the export engine must use the QualifyText property set for that Column object. When the QualifyText property is null on a Column object, the export engine must use the value of the QualifyText property on the parent Record of a column.
My head asplode!
Calling all South African developers! Your participation in this local dev community will be mutually beneficial, to you and us.
-
OK, Record is my parent object (not base object), and it has a collection of child Column objects. Record has a boolean property, QualifyText, which when set, surrounds string columns with a configured qualifying character. Column, a child object, also has a QualifyText property. If this property is set on a Column object, the export engine must use the QualifyText property set for that Column object. When the QualifyText property is null on a Column object, the export engine must use the value of the QualifyText property on the parent Record of a column.
My head asplode!
Calling all South African developers! Your participation in this local dev community will be mutually beneficial, to you and us.
Brady, it's possible we are at an impasse on design fundamentals. Perhaps I am having difficulty providing any suggestions of how to deal with your problem as you have framed it because I see a larger problem in your design. Things like your previous statement...
Brady Kelly wrote:
I have a hierarchy of objects that share some attributes
... point to fundamental design flaws for me.
-
Brady, it's possible we are at an impasse on design fundamentals. Perhaps I am having difficulty providing any suggestions of how to deal with your problem as you have framed it because I see a larger problem in your design. Things like your previous statement...
Brady Kelly wrote:
I have a hierarchy of objects that share some attributes
... point to fundamental design flaws for me.
Mike, I think the problem is with my description, not my design. I am looking to implement something somebody likened to Ambient Properties[^]. If I don't specify a background colour for an edit control I place on a container, I would like that control to assume the background colour of its container. If don't specify a QualifyText flag for a Column, I want the consumer of the Column object to use the QualifyText flag of its parent, the Record. I want to keep this logic encapsulated in the code that defines Record or Column, not in the code that uses them. There may be more purist ways of doing this, but it is by no means an abominable design requirement.
My head asplode!
Calling all South African developers! Your participation in this local dev community will be mutually beneficial, to you and us.
-
Mike, I think the problem is with my description, not my design. I am looking to implement something somebody likened to Ambient Properties[^]. If I don't specify a background colour for an edit control I place on a container, I would like that control to assume the background colour of its container. If don't specify a QualifyText flag for a Column, I want the consumer of the Column object to use the QualifyText flag of its parent, the Record. I want to keep this logic encapsulated in the code that defines Record or Column, not in the code that uses them. There may be more purist ways of doing this, but it is by no means an abominable design requirement.
My head asplode!
Calling all South African developers! Your participation in this local dev community will be mutually beneficial, to you and us.
-
Brady Kelly wrote:
but it is by no means an abominable design requirement.
Ok, i'm convinced. Good luck. Just in case you might find this interesting[^]. or this[^]
Thanks, I am finding them interesting, but have to continue tomorrow. It's now 23h40 here and I'm going home.
My head asplode!
Calling all South African developers! Your participation in this local dev community will be mutually beneficial, to you and us.
-
Brady Kelly wrote:
but it is by no means an abominable design requirement.
Ok, i'm convinced. Good luck. Just in case you might find this interesting[^]. or this[^]
Does that guy really advocate not using properties? I think it's a bit bizzare as i rely on properties for injections via routes other than constructors. Sure they don't get used much at higher levels, but for primitive types they are essential. Generally tho, i can't agree. I'm guessing the guy asking the questions is trying to implement something along the same lines as the VS designer with inherited attributes for defaults, whether or not its appropriate for his domain is another thing entirely.
------------------------------- Carrier Bags - 21st Century Tumbleweed.
-
Does that guy really advocate not using properties? I think it's a bit bizzare as i rely on properties for injections via routes other than constructors. Sure they don't get used much at higher levels, but for primitive types they are essential. Generally tho, i can't agree. I'm guessing the guy asking the questions is trying to implement something along the same lines as the VS designer with inherited attributes for defaults, whether or not its appropriate for his domain is another thing entirely.
------------------------------- Carrier Bags - 21st Century Tumbleweed.
Tristan Rhodes wrote:
Does that guy really advocate not using properties?
It's slightly more complicated than that. If you read Holub's article I would start by saying he has far more experience and skill than I will ever have. Also his writing is far superior to mine, therefore my attempt to clarify his words seems silly but here goes. I work with people who think that just because the code they write has classes in it they are doing object oriented programming. Nothing could be further from the truth. That is what Holub's point is. Just because you write a class doesn't mean you are doing object oriented "design". Holub points out that many people are doing just that. They write a class making the attributes private (data hiding) good start, but then they expose them, and worse "use them" from other classes thereby reversing the "hidden" aspect of the data. Again the point is not to not use properties it's to wake up and try to understand the point of "data hiding", what the benefits are and why it's a "principle" of Object Oriented Design. Basically all you do when resort to using public properties is give up on that principle of OOD and fall back to procedural design. Along with that decision you incur the technical debt[^] that comes with it. The technical debt is the reason it's bad, it's not a religious argument it's a practical argument. That's why it doesn't matter if you or anyone else agrees with Holub, all that matters is reality and he has a better grip on it, when it comes to software development, than most of us. Well that's my two cents worth and that's about all it's worth, I doubt it is helpful to you or anyone else.
-
Tristan Rhodes wrote:
Does that guy really advocate not using properties?
It's slightly more complicated than that. If you read Holub's article I would start by saying he has far more experience and skill than I will ever have. Also his writing is far superior to mine, therefore my attempt to clarify his words seems silly but here goes. I work with people who think that just because the code they write has classes in it they are doing object oriented programming. Nothing could be further from the truth. That is what Holub's point is. Just because you write a class doesn't mean you are doing object oriented "design". Holub points out that many people are doing just that. They write a class making the attributes private (data hiding) good start, but then they expose them, and worse "use them" from other classes thereby reversing the "hidden" aspect of the data. Again the point is not to not use properties it's to wake up and try to understand the point of "data hiding", what the benefits are and why it's a "principle" of Object Oriented Design. Basically all you do when resort to using public properties is give up on that principle of OOD and fall back to procedural design. Along with that decision you incur the technical debt[^] that comes with it. The technical debt is the reason it's bad, it's not a religious argument it's a practical argument. That's why it doesn't matter if you or anyone else agrees with Holub, all that matters is reality and he has a better grip on it, when it comes to software development, than most of us. Well that's my two cents worth and that's about all it's worth, I doubt it is helpful to you or anyone else.
Ok, i think i get it, but i need some concrete examples. For instance - the class below has a reasonable use of properties.
class Validator { //Validation Code public bool _Valid { get{return _isValid;} } }However, if you have the following, you are breaking the encapsulation of the IsValid value, and moving what should be internal logic to outside the class:class Validator { //Data Walking Code public bool _Valid { get{return _isValid;} set{_isValid = value;} } //Events raised when validation happens }(Ok, i REALLY had to think for that second example) Does that sound about right? T------------------------------- Carrier Bags - 21st Century Tumbleweed.
-
Ok, i think i get it, but i need some concrete examples. For instance - the class below has a reasonable use of properties.
class Validator { //Validation Code public bool _Valid { get{return _isValid;} } }However, if you have the following, you are breaking the encapsulation of the IsValid value, and moving what should be internal logic to outside the class:class Validator { //Data Walking Code public bool _Valid { get{return _isValid;} set{_isValid = value;} } //Events raised when validation happens }(Ok, i REALLY had to think for that second example) Does that sound about right? T------------------------------- Carrier Bags - 21st Century Tumbleweed.
Tristan Rhodes wrote:
Does that sound about right?
Realize this issue is about Object Oriented Design. For most of us we are students for a long time, maybe forever. Don’t expect to obtain a 100% understanding in a few days.
In the concrete example you posted you have focused on the idea that exposing the data through a setter is where the design goes off track. It is an indication of a poor design, it’s not “the” problem. A more complete analysis is required. What is the purpose of the Validator class? Having a class that just determines the Boolean state and then simply exposes the state might indicate a larger design issue. Other elements of the design must be considered to know the answer.