In Java plz due today Assignment 4 - Email, Shwitter and Inheritance

Select one option from below. All (both) options are worth the same number of points. The more advanced option(s) are provided for students who find the basic one too easy and want more of a challenge. OPTION A (Basic): Message, EMail and Tweet Understand the Classes and Problem Every message contains some content ("The British are coming! The British are coming!"). We could enhance this by adding other traits (author, date and/or time of creation), but let's keep things simple and say that this is the only aspect of a basic message. Some messages, however, have further components that define them. For example, an email consists of a normal message, plus at least two other items: a from email address and a to email address. An email is a message, but a special kind of message. So we can smell inheritance in the neighborhood. A message seems like it will make a good base class, and an email, having an is a relationship with message, is a good candidate for a derived class or extension of the base class message. Meanwhile, a tweet consists of a normal message, plus at least one other item: a from user id. An tweet is a message, too. It has a different kind of specialization than an email has, so it is a different extension of the base class. (We are not considering a direct tweet, which would also require a to user id.) Not only will both emails and tweets contain extra data than the base class, message, but in at least one instance we will see the same member (the content) have a different kind of restriction in the derived class than in the base class (can you guess what I'm suggesting before you read on?). Thus, even though we store the tweet content in the base class member, without the need for a new content area for the tweet, we will still have a different validation of the length of that message content. Warning: Because it makes sense to do so, we are going to name the message content message and the message class Message. So what I called content in the above paragraph will be known as (lower-case) message in what comes next. The class, itself, will be (upper-case) Message. You'll see. Just keep reading. File Structure: You will use one file for the entire program, so the non-Foothill classes should be non-public. The Base Class: Message Your base class is named Message. Public or Protected (your choice) Static Class Constants Define a full set of limits and defaults, like MAX_MSG_LENGTH, for both min, max length and default data of the member. Set the maximum message length to 100,000. Private Member Data String message; Public Methods Default and 1-parameter constructors. Mutator and Accessor for the member. a toString() method that provides a nicely formatted return String for potential screen I/O. Private Methods private static validation helper to filter client parameters. These will support your public methods. Recommended test of Class Message Instantiate two or more Message objects, some using the default constructor and some using the parameter-taking constructor. Mutate the member, and after that use the toString() to assist a screen output so we can see what all of your objects contain. Next, test the accessor. Finally, test the mutator, providing both legal and illegal arguments and testing the return values (thus demonstrating that the mutator does the right thing). Here is a sample run from my test (but you will have to imagine/deduce the source I used and create your own source for your testing, which will produce a different output). Example Test Run of Message Class /* --------------------------------------------------------- Base Class Testing ****************************** Message ---------------------- Some messages just aren't worth sending. Message ---------------------- hello world testing Message accessor: hello world testing Message mutator: too long (as expected) Message ---------------------- Some messages just aren't worth sending. acceptable length (should be) Message ---------------------- LONG STRING abcde abcde abcde abcde abcde abcde abcde abcde abcde abcde abc de abcde abcde abcde abcde abcde --------------------------------------------------------- */ The Derived Class: Email Your first derived class is named Email. Email uses the member already present in the base class; the Email's message is the message of the base class. Do not try to store an Email's message body as a new member of the derived class or you will get get a 0 on the assignment -- not desirable by you or me. Duplicating base class data in derived class means you do not understand what inheritance is, thus the significance of this kind of mistake. Public Static Class Constants To the existing base class statics, add at least two with names and meanings similar or identical to MAX_EMAIL_ADDRESS_LENGTH and DEFAULT_EMAIL_ADDRESS. Look up the maximum length of an email address, and make sure yours is no larger than that (but you can make it smaller for easier testing). Additional Private Member Data String fromAddress; String toAddress; Public Methods Default and 3-parameter constructors. Use constructor chaining. Mutators and Accessors for the new members. Override those methods of the base class for which it makes sense to do so. Think about this and come to your own conclusions. Private Methods private static validation helper to filter a bad email address. You should do the minimum, but you don't have to be more complete than that. This is just to show that you can perform basic filtering. The minimum is a method isValidEmailAddress(), which tests for both length and the existence of at least one '@' and one '.' character. Further is up to you, but don't overdo it or be too restrictive. Recommended test of Class Email Similar to the Message class. The Derived Class: Shweet (It is like a Twitter Tweet, but since I can't be certain that the details of a Tweet are exactly what I state here, we will disengage this from Twitter, and make the constraints that I impose accurate for a Shweet by decree.) Shweet uses the member already present in the base class; The Shweet's message is the message of the base class. Do not try to store a Shweet's message body as a new member or you will get a 0 on the assignment, as mentioned above. Public Static Class Constants To the existing base class statics, add three: MAX_SHWITTER_ID_LENGTH (15), MAX_SHWEET_LENGTH (140) and DEFAULT_USER_ID. While the MAX_SHWEET_LENGTH is going to be smaller than the base class's MAX_MSG_LENGTH, do not assume this fact in your implementation. A valid message length for a Shweet has to be smaller than both of these values. If it's not a valid base class message, it isn't a valid Shweet message, and this should be true if we later change the MAX_SHWEET_LENGTH length to be 50 million. Additional Private Member Data String fromID; Public Methods Default and 2-parameter constructors. When it is possible and meaningful, use constructor chaining. Think about which constructor to chain to. Mutator and Accessor for the new member. Override those methods of the base class for which it makes sense to do so. Think about this and come to your own conclusions. You have to somehow enforce the length limits of both the base class and the derived class for the same message member. Private Methods private static validation helpers (plural) to filter out bad tweets and shwitter IDs. Create an isValidShweet() for the message. Also, create an isValidShwitterID() for the Shwitter ID. But also, make a third, even lower-level, helper that would make isValidShwitterID() clear and short. This helper-helper should be named stringHasOnlyAlphaOrNumOrUnderscore() and that name tells you the kind of thing it should do: it should make sure the shwitter ID contains only some combination of letters, numbers or an underscore ('_'). Also, I don't care whether you decide that the Shwitter ID be case sensitive. If you don't know what String or Character methods can be used for this, look them up online. They are very easy to find. Recommended test of Class Shweet Similar to the Message class. Example Test Run of Shweet Class (done in same run as overall program run) OPTION B - A Stack of Messages Complete, for submission, OPTION A. Add StackNode and Stack classes, exactly as presented in the Modules. (I prefer one file, so these new classes should be non-public). Next, derive MessageNode and MessageStack classes in the same manner as we derived FloatNode and FloatStack in the modules, but making adjustments, as needed, to have the MessageStack work with Messages. Change any methods named showXYZ() by converting them to toString() so that the client, not the methods, does the output. The new toString() method (or methods) merely format(s) the Strings in preparation for output. In your client, after you have done the things from OPTION A, add code to create a MessageStack. Then pushMessage() all the various Messages onto the stack. This means that some messages will be base class objects and some will be derived class objects. But the code to push and pop them in the client is the same. Nothing special need be done in order to push one kind of Message vs. another kind. That is, if you are doing this right, you just pushMessage(someMsg) regardless of what flavor of Message someMsg happens to be, and likewise with the popping. Finally, in a loop, popMessage() everything off the MessageStack and print it out as you popMessage(). Go beyond the end of the Stack so you can confirm that your code does not break when you popMessage() things off an empty Stack. If working correctly, this option will print the base class data if a base class object is popped off the stack, but will print the extra derived data if a derived class object is popped. This is a consequence of overriding toString() which is already part of OPTION A. This has to happen by just calling toString() on the pop()ped references without the client having to do anything special.