Another week down. I understand why you want pieces to be private. I don't want everyone knowing all of my business and I am a pretty private guy. I like my privacy. There are certain things we all tell people and other pieces we keep to ourselves (or share with only a select few). I like the sentence at the beginning of the chapter that states "...good objects don't let other objects go poking around their fields." Enter encapsulation.
Encapsulation allows you to keep your privates private without impacting the integrity of your program. I can tell my class that, hey, this parameter or method is private and only this class can use it. It's like keeping a secret. The problem becomes, when do I make something private vs. public? I guess that is a subject that one really needs to think about when programming. Some pieces are ok to be viewed by the entire program while others we want to keep locked down, we just want to get it write to help with the readability and ability to understand our code. Nothing new to programmers that have been in the game, but I found this piece helpful.
To help with encapsulation you have properties, or the get and set accessors. I know, right? Honestly, I see that these work, but am fuzzy on the how they work. Ok, I reread a paragraph. It states "A property can be used to get or set a backing field, which is just a name for a field set by a property." I need to go back and keep a list of vocabulary words. I have to keep looking up what the different words mean. Anyway, I am fuzzy here, but I could just use the automatic properties and we will be all good right? I mean, type prop, tab, tab and it is done! Well, I still need to understand what this is doing to make the program work as expected in a clean way. Plus, I am sure just throwing gets and sets out there doesn't help with encapsulation and determining if I should have a public or private object.
More reading this week on this subject...watch for it
A screen shot from the program the book helped walk me through
Encapsulation allows you to keep your privates private without impacting the integrity of your program. I can tell my class that, hey, this parameter or method is private and only this class can use it. It's like keeping a secret. The problem becomes, when do I make something private vs. public? I guess that is a subject that one really needs to think about when programming. Some pieces are ok to be viewed by the entire program while others we want to keep locked down, we just want to get it write to help with the readability and ability to understand our code. Nothing new to programmers that have been in the game, but I found this piece helpful.
To help with encapsulation you have properties, or the get and set accessors. I know, right? Honestly, I see that these work, but am fuzzy on the how they work. Ok, I reread a paragraph. It states "A property can be used to get or set a backing field, which is just a name for a field set by a property." I need to go back and keep a list of vocabulary words. I have to keep looking up what the different words mean. Anyway, I am fuzzy here, but I could just use the automatic properties and we will be all good right? I mean, type prop, tab, tab and it is done! Well, I still need to understand what this is doing to make the program work as expected in a clean way. Plus, I am sure just throwing gets and sets out there doesn't help with encapsulation and determining if I should have a public or private object.
More reading this week on this subject...watch for it
A screen shot from the program the book helped walk me through
No comments:
Post a Comment