Skip to main content

Timeline for Console Address Book application

Current License: CC BY-SA 3.0

18 events
when toggle format what by license comment
May 6, 2017 at 4:35 comment added user33306 the way I re-designed the classes, you can access them through normal instantiation. You can have the option of allowing the user to maintain more than one contactList. I would suggest keeping each function in the class where it's designed for. You don't want to cross the boundaries of encapsulation. A menuing system inside the AddressBook class, will be the front end for the classes, and will let the user enter any raw data that's needed. One thing to remember, what the programming language will allow and the design philosophy you want to follow don't always have strict coherence.
May 5, 2017 at 17:45 comment added Nibble15 @tinstaafl if the former is true, could I then make properties in the AddressBook class to make use of these sub-class members easier to use?? say: public string addContact = ContactCollection.AddEntry(); so then all I have to enter is myAddressBook.addContact();??
May 5, 2017 at 17:30 comment added Nibble15 @tinstaafl My guess would be the former, but I don't want to guess. If it's the latter, then I think I could safely say that any members of the parent class(AddressBook) would be accessible to the parent as if they were part of the class itself, since they technically are. I would equate the former to a javascript object literal where the value of the key could be another object and one of its values could be a function where: let parentObj = { parentKey: { subKey: function (){ ... }}}; would use: parent.parentKey.subKey(); to call the function.
May 5, 2017 at 17:16 comment added Nibble15 @tinstaafl This is my first chance to sit down since the last entry I made. I apologize for not getting back to you sooner. A couple of things, since this is beyond where we are in the course, but I want to understand nested classes. First, and probably a more simple answer, when accessing a nested class from, say class Program, I would first have to instantiate the class AddressBook myAddressBook = new AddressBook(); then how do I access the nested classes, by typing myAddressBook.ContactCollection.EditEntry();, or just myAddressBook.EditEntry();?
May 4, 2017 at 18:10 comment added user33306 @Nibble15 - I made a change to the sample I gave you. On further reflection, I realized that it would make displaying the contact info easier if the Contact class was outside the ContactList class.
May 4, 2017 at 18:07 history edited user33306 CC BY-SA 3.0
deleted 63 characters in body
May 4, 2017 at 4:29 comment added user33306 Actually only 2 are nested. In any case it's more to demonstrate a point about design. In fact I've been thinking it might be better to have Contact only one level deep.
May 4, 2017 at 4:26 comment added t3chb0t Three nested classes... isn't it too much? ;-]
May 3, 2017 at 23:24 comment added Nibble15 That was what I once had - private set; I think I see how you made it so I would have better encapsulation/abstraction. EditEntry() would make a call to EditInfo() instead of dot notation from AddressBook to update the property members of Contact. I posted this on Treehouse and the only person that responded(it's a small community for c# in comparison to the others) mentioned the override for ToString() and it's something I intend on looking into. I will refer back to what you have given me as I move forward. Oh, and no worries on the typo, you're helping me and for that I'm grateful.
May 3, 2017 at 22:52 history edited user33306 CC BY-SA 3.0
added 81 characters in body
May 3, 2017 at 22:51 comment added user33306 Sorry for the search typo that should have been Dictionary<string,List<Contact>>. I've added more about the structure to perhaps make it a little more clear.
May 3, 2017 at 22:46 history edited user33306 CC BY-SA 3.0
added 1062 characters in body
May 3, 2017 at 22:39 history edited user33306 CC BY-SA 3.0
added 6 characters in body
May 3, 2017 at 22:15 comment added Nibble15 Continuing with my assumptions, by collection you're referring to the Dictionary<s, Contact> that you mentioned. So, public AddressBook(){} and the AddressBook field that I have now would then be a part of the ContactCollection class and possibly GetEntryIndex() ContainsEntry() and RemoveEntry(), as well, but using Dictionary(which I need to look up what that is). The methods I just mentioned don't really have anything to do specifically with the interface, that is why I am thinking this.
May 3, 2017 at 22:15 comment added Nibble15 If items declared are part of the Contact class wouldn't they need to be public to be accessed from the outer scope that AddressBook() has? Or, does scope not apply in the same manner in this case? eg: the 'i' variable declared in a for loop's statement is within a method, but not accessible outside of the loop, therefore only in the scope of the loop. Either way, all of this, to be clear, would bring my files down to two - Program.cs with Main() and then my AddressBook and Contact classes rolled into one with the collection added to it, instead of the three that I have now.
May 3, 2017 at 22:14 comment added Nibble15 I have gone from private to public with the Contact.cs properties a couple of times. I had trouble figuring out how to work with them without them being public. I had no idea you could set up multiple classes in one file like this and have it be considered good practice. It is good to know but adds another layer of needing to understand how that works. It would cover the issue with access to the Contact.cs properties, maybe. I assume this because Contact, in your example, is nested within the AddressBook class. But, what about scope?
May 3, 2017 at 21:02 history edited user33306 CC BY-SA 3.0
added 224 characters in body
May 3, 2017 at 20:57 history answered user33306 CC BY-SA 3.0