OOP Programming, Two approachs for a problem
-
Hello, I'm making an email client as a homework. Its supposed to have multiple account support, contacts, etc. But im in a discussion with another person about an OOP thing, We have the class "Message", and it contains the fields from, to, bcc, cc, and of course others, but this problem is focused on those fields. Considering that: -A message can contain multiple emails in the to, bcc, and cc field. -For whatever reasons we have the classes Account and Contact One approach: To have all these fields of type string, that is:
from : string
to : List< string >
bcc : List< string >
cc : List< string >Second approach: To have the class Person (with the fields name and email) which is a generalization of Account and Contact, that is: Account extends Person Contact extends Person And in the class Message, to have these fields of type Person, that is:
from : Person
to : List< person >
bcc : List< person >
cc : List< person >I would go for the second approach but the other person insists on going with the 1st choice, and I don't know how to convince it, and to convince myself that i'm right. SORRY BAD ENGLISH!
-
Hello, I'm making an email client as a homework. Its supposed to have multiple account support, contacts, etc. But im in a discussion with another person about an OOP thing, We have the class "Message", and it contains the fields from, to, bcc, cc, and of course others, but this problem is focused on those fields. Considering that: -A message can contain multiple emails in the to, bcc, and cc field. -For whatever reasons we have the classes Account and Contact One approach: To have all these fields of type string, that is:
from : string
to : List< string >
bcc : List< string >
cc : List< string >Second approach: To have the class Person (with the fields name and email) which is a generalization of Account and Contact, that is: Account extends Person Contact extends Person And in the class Message, to have these fields of type Person, that is:
from : Person
to : List< person >
bcc : List< person >
cc : List< person >I would go for the second approach but the other person insists on going with the 1st choice, and I don't know how to convince it, and to convince myself that i'm right. SORRY BAD ENGLISH!
Wouldn't the Person class support multiple email addresses too? I have several. How about an IAddress interface (I have no idea what it may contain) which EmailAddress (and others) implements. Person can then have a List<IAddress> and some instances of Person may contain instances of EmailAddress and an email message will use List<EmailAddress> You may also want to look at the classes in System.Net
-
Hello, I'm making an email client as a homework. Its supposed to have multiple account support, contacts, etc. But im in a discussion with another person about an OOP thing, We have the class "Message", and it contains the fields from, to, bcc, cc, and of course others, but this problem is focused on those fields. Considering that: -A message can contain multiple emails in the to, bcc, and cc field. -For whatever reasons we have the classes Account and Contact One approach: To have all these fields of type string, that is:
from : string
to : List< string >
bcc : List< string >
cc : List< string >Second approach: To have the class Person (with the fields name and email) which is a generalization of Account and Contact, that is: Account extends Person Contact extends Person And in the class Message, to have these fields of type Person, that is:
from : Person
to : List< person >
bcc : List< person >
cc : List< person >I would go for the second approach but the other person insists on going with the 1st choice, and I don't know how to convince it, and to convince myself that i'm right. SORRY BAD ENGLISH!
So the big question has to be: Why do you think your approach is right? If you can't convince yourself its the one to go with, you'll have a job convincing someone else. To make it easier to come up with an answer use just the 'to' as an example as the other lines, bcc, cc etc are similar. What do you get, if anything, using Person that you don't get using String? Or conversly: What do you get using String that you don't get using Person? If there is a difference here, Does the user of the email system you are designing want whatever benifits that difference brings?
-
So the big question has to be: Why do you think your approach is right? If you can't convince yourself its the one to go with, you'll have a job convincing someone else. To make it easier to come up with an answer use just the 'to' as an example as the other lines, bcc, cc etc are similar. What do you get, if anything, using Person that you don't get using String? Or conversly: What do you get using String that you don't get using Person? If there is a difference here, Does the user of the email system you are designing want whatever benifits that difference brings?
What do I get using Person that I don't get using String: That future operations will be easier because of treating with an object person than a string, for example searching, or showing the person info (lets say a picture, or the fullname, or whatever) when reading the message. Of course I can do that too if those fields are strings but I think i would have more hardcoding instead... Am i right? also conceptually I would have object connections between a person and a contact, which wouldnt be that explicit if those fields where strings Thats why I defend the Person class
-
What do I get using Person that I don't get using String: That future operations will be easier because of treating with an object person than a string, for example searching, or showing the person info (lets say a picture, or the fullname, or whatever) when reading the message. Of course I can do that too if those fields are strings but I think i would have more hardcoding instead... Am i right? also conceptually I would have object connections between a person and a contact, which wouldnt be that explicit if those fields where strings Thats why I defend the Person class
Hi, That future operations will be easier because of treating with an object person than a string.. Leaving aside whether these future operation will be easier this way or not for a second, it's homework - you've only got a limited amount of time to design and code a limited amount of features. So you really need to decide what those features are before coding i.e What are you going to do. Only after that, decide how to do it. Just like any Project - homework or otherwise. For example searching, or showing the person info (lets say a picture, or the fullname, or whatever) when reading the message... Searching for what? You have do decide befor starting the coding. Are you going to want to display a picture for every email you read? You won't have one for most of the spam you get! Do you have to display the fullname of every email you read? Again a lot is junk so you won't be able to for everyone 'Or whatever': The 'whatever' bits derail lots of projects because nobody has decided what features are being aimed at, they've just sat down and started coding. A message can contain multiple emails in the to, bcc, and cc field Decide exactly what a message is. Is it an email (rather than multiple emails) with multiple addresses rather than multiple emails? Of course I can do that too if those fields are strings but I think i would have more hardcoding instead... to be honest I'd say its hard to tell how much coding will be needed either way at this stage. Though I see what your point is. Am i right? also conceptually I would have object connections between a person and a contact, which wouldnt be that explicit if those fields where strings One of the biggest slip-ups I see, and which I made, when starting OOP is to have all the objects dependant upon (know about) one another. Object A knows about object B which knows about C, D, E etc and when you want to make a little change to one it affects them all and gets complicated. Get used to thinking what the User wants. If the User wants stuff like being able to hover their mouse over an address in an email and have details pop up, it may be that being able to link that address to the Person object will be handy. I'd think of another object or just code that combines other objects - The-email-editor as well. This could do the hard work of linking addresses to Persons, and could keep the Message and Person objects separate. Sorry if I'm not saying Yes/No you should
-
What do I get using Person that I don't get using String: That future operations will be easier because of treating with an object person than a string, for example searching, or showing the person info (lets say a picture, or the fullname, or whatever) when reading the message. Of course I can do that too if those fields are strings but I think i would have more hardcoding instead... Am i right? also conceptually I would have object connections between a person and a contact, which wouldnt be that explicit if those fields where strings Thats why I defend the Person class
Quake2Player wrote:
What do I get using Person that I don't get using String:
I don't know, how are we supposed to know that, we don't have your requirements nor your design documentation. You know things like Use Cases and CRC cards. You say you are a student, do they have you learnCRC Cards[^]? If not you should. Notice item #3 "The responsibilities of the class." Responsibility is key in determining design and the answer to your question "what do I get".
-
Hi, That future operations will be easier because of treating with an object person than a string.. Leaving aside whether these future operation will be easier this way or not for a second, it's homework - you've only got a limited amount of time to design and code a limited amount of features. So you really need to decide what those features are before coding i.e What are you going to do. Only after that, decide how to do it. Just like any Project - homework or otherwise. For example searching, or showing the person info (lets say a picture, or the fullname, or whatever) when reading the message... Searching for what? You have do decide befor starting the coding. Are you going to want to display a picture for every email you read? You won't have one for most of the spam you get! Do you have to display the fullname of every email you read? Again a lot is junk so you won't be able to for everyone 'Or whatever': The 'whatever' bits derail lots of projects because nobody has decided what features are being aimed at, they've just sat down and started coding. A message can contain multiple emails in the to, bcc, and cc field Decide exactly what a message is. Is it an email (rather than multiple emails) with multiple addresses rather than multiple emails? Of course I can do that too if those fields are strings but I think i would have more hardcoding instead... to be honest I'd say its hard to tell how much coding will be needed either way at this stage. Though I see what your point is. Am i right? also conceptually I would have object connections between a person and a contact, which wouldnt be that explicit if those fields where strings One of the biggest slip-ups I see, and which I made, when starting OOP is to have all the objects dependant upon (know about) one another. Object A knows about object B which knows about C, D, E etc and when you want to make a little change to one it affects them all and gets complicated. Get used to thinking what the User wants. If the User wants stuff like being able to hover their mouse over an address in an email and have details pop up, it may be that being able to link that address to the Person object will be handy. I'd think of another object or just code that combines other objects - The-email-editor as well. This could do the hard work of linking addresses to Persons, and could keep the Message and Person objects separate. Sorry if I'm not saying Yes/No you should
Sorry if I'm not saying Yes/No you should use the Person class, but its your homework after all and I'm just trying to make you think of some of the reasons why you would decide Yes or No. One definite thing is, that by being able to code Person without knowing about the design/code of Message and vice-vera you have an advantage. Thanks for replying. I think you summarize my whole point of view in your last paragraph. About what a message is, maybe I messed up things when saying "a message can contain multiple emails in the to, bcc, cc fields", i was referring to "multiple addresses".
-
Hello, I'm making an email client as a homework. Its supposed to have multiple account support, contacts, etc. But im in a discussion with another person about an OOP thing, We have the class "Message", and it contains the fields from, to, bcc, cc, and of course others, but this problem is focused on those fields. Considering that: -A message can contain multiple emails in the to, bcc, and cc field. -For whatever reasons we have the classes Account and Contact One approach: To have all these fields of type string, that is:
from : string
to : List< string >
bcc : List< string >
cc : List< string >Second approach: To have the class Person (with the fields name and email) which is a generalization of Account and Contact, that is: Account extends Person Contact extends Person And in the class Message, to have these fields of type Person, that is:
from : Person
to : List< person >
bcc : List< person >
cc : List< person >I would go for the second approach but the other person insists on going with the 1st choice, and I don't know how to convince it, and to convince myself that i'm right. SORRY BAD ENGLISH!
For not making another topic, I have an encapsulation debate with myself: Account contains List< Contact > and List< ContactGroup >, and methods to manage these.. How should I DECIDE if I should encapsulate all the contacts classes and methods in lets say an AddressBook class? The same for other things contained in Account, like all concerning Messages: List< Labels >,List< Messages >, List< MessageThread > and methods.. My great question would be that if I have a lot of encapsulation, then I would have a lot of inbetween methods, from the main application to the object itself, like... Application.AddLabelToMessage() calling Account.AddLabelToMessage(msg, label) calling MessageManagerOrSomething.AddLabelToMessage(msg, label) calling certain Label as Label.AddMessage(msg) Please have patience, i'm learning to model well (I know these can be done either way) Again sorry bad eng.
-
For not making another topic, I have an encapsulation debate with myself: Account contains List< Contact > and List< ContactGroup >, and methods to manage these.. How should I DECIDE if I should encapsulate all the contacts classes and methods in lets say an AddressBook class? The same for other things contained in Account, like all concerning Messages: List< Labels >,List< Messages >, List< MessageThread > and methods.. My great question would be that if I have a lot of encapsulation, then I would have a lot of inbetween methods, from the main application to the object itself, like... Application.AddLabelToMessage() calling Account.AddLabelToMessage(msg, label) calling MessageManagerOrSomething.AddLabelToMessage(msg, label) calling certain Label as Label.AddMessage(msg) Please have patience, i'm learning to model well (I know these can be done either way) Again sorry bad eng.
How should I DECIDE if I should encapsulate all the contacts classes and methods in lets say an AddressBook class? Does the word ('AddressBook' in this case) come up often (preceded by 'the') when you talk or think about the design and how to do it? If so it's probably a good contender to be an object. Then, consider if you can come up with messages (methods) such as Set...., Get....., Do....., that you would use on this object to have it do things. Should one class contain other classes? Ask: "Does Class1 have a Class2 OR Is Class1 a type of Class2, if its the first one, Class 1 should contain Class2. Consider your: List, what happens if near the end of your coding you decide to change to, say vector or String Messages[50]. If you've written a class CMessages with methods, say, GetMessage(...) and AddMessage(..) which encapsulate this, then it's no problem. If youve used list here there and everywhere in the code it can be a real problem to change them all. a lot of inbetween methods? Being able to call Application.AddLabelToMessage(...) is probably better than needing to use four or five lines to get one object, then another from that, then another from that and finally to call, say, MsgHeader.AddLabel. You don't want to bother low level objects like, say, MsgHeader objects at a high level. Just calling AddLableToMessage hides the complication that (may) be in the method from the caller. Encapsulation is all about hiding complication. In the end, does it feel right? This may take experience but if it feels right, go for it.