requently sked uestions

(שאלות שכיחות ותשובותיהן)

· Eclipse

· Object Oriented and Java

· Exercise 1

· Exercise 2

· question 1

· question 2

· Exercise 3

· Exercise 4

· Exercise 5

· Monopoly Project part 1

· Monopoly Project part 2

חשוב מאוד!

לתרגילים בקורס יש יותר מפתרון אחד נכון. האמור באתר זה אינו מהווה שינוי בדרישה המקורית המופיעה בתרגילים אלא רק הבהרות (ואולי בחלק מן המקרים גם הקלות). פתרונות סבירים השונים מן האמור למטה יתקבלו בברכה.

Last updated: 6/14/2006 1:52 PM

Eclipse

Question: How can i tell Eclipse to use src/ as source folder? (and not as top level package…)

Answer: Good question. Open your Eclipse. Choose Project -> Properties -> Java Build Path -> Source -> Add Folder. Folder Name: src. Eclipse would ask you if you'd like to change the output folder as well…

Question: I can't find "CVS Repository Exploring" perspective, to work with CVS inside Eclipse.

Answer: Try to open "Team Synchronizing" perspective instead. Then open the views from Window -> Show View -> Other -> CVS

Question: I can't find "cvs update" option in Eclipse.

Answer: In "Team Synchronizing" open "Synchronize" view and right click your project. The Synchronize option would do the work.

Object Oriented and Java

שאלה: האם יש צורך להעתיק לחוזה של מחלקה מרחיבה (EXTENDS) את התנאים שהוגדרו במחלקת הבסיס - או רק להוסיף תנאים על התנאים שכבר נכתבו במחלקת הבסיס? לדוגמא: בשקפים רואים שבמחלקה המממשת מנשק אין צורך להעתיק את החוזה של מחלקת המנשק, אלא רק להוסיף את התנאים נוספים אחרים.

תשובה: העיקרון נשמר. הדבר אמור גם לגבי הרחבה (extends) וגם לגבי מימוש (implements) – יש לציין רק את התנאים החדשים (המחזקים או המקלים את החוזה).

שאלה: באופן כללי אין אפשרות לעשות ירושה מרובה בJAVA (בניגוד ל-C++), אך מה קורה אם דבר זה נחוץ? לדוגמא (המצאתי לבד, אין קשר לש.ב J) יש ליצור 4 מחלקות:

1. סירה
2. סירה עם מפרש (נניח צריך רק להוסיף Seter ו-Geter למפרש)
3. סירה עם מנוע (נניח צריך רק להוסיף Seter ו-Geter למנוע)
4. סירה עם מפרש ומנוע (להוסיף את מה שכתוב ב-2 ו -3)

 איך אני מבצע את הדיזיין? כך אני עשיתי ב-ש.ב, (מסתבר שזה לא נכון, ירדו לי 10 נק')

1. אינטרפייס לסירה
2. אינטרפייס ל- "בעל מפרש"
3. אינטרפייס ל-"בעל מנוע"

1. ליצור מחלקת סירה שמממשת את "סירה"
2. ליצור מחלקת סירה עם מפרש שמממשת את "בעל מפרש" ויורשת ממחלקה מס 1 ומממשת את הפונ' הנוספות.
3. ליצור מחלקת סירה עם מנוע שמממשת את "בעל מנוע" ויורשת ממחלקה מס 1 ומממשת את הפונ' הנוספות.
4. ליצור מחלקת סירה עם מפרש ומנוע שמממשת את "בעל מפרש" ו "בעל מנוע" ויורשת ממחלקה מס 2 ומממשת את הפונ' הנוספות (שכבר כתובות ב-3)

בעצם נוצר כאן שיכפול קוד בין 3 ל-4, אבל אני לא רואה שום דרך לפתור את זה (ב-JAVA לפחות), מה התשובה הנכונה?

תשובה: אין תשובה נכונה, אבל יש כמה חלופות.

נציג את אחת האפשרויות. ראשית, ננסה להבין את הבעייתיות בתשובה שלך: "סירה עם מפרש ומנוע" לא מכילה בתוכה "סירה עם מפרש" או "סירה עם מנוע" (למרות שלפעמים to be is also to have הכיוון ההפוך שכיח פחות).

מדוע לא להגדיר את המחלקות "מפרש" ו- "מנוע" ואותן להכיל במחלקה "סירה". יש מנוע? יופי. אין ? ההפנייה תהיה null .

אפשרות אחרת תהיה לנסות לשלב ירושה עם הדבר הזה. אולי ע"י האצלה ל "אמצעי הנעה" שהוא עצמו עץ ירושה או אולי אוסף של אמצעי הנעה...

חשוב לתקן את הבעיה העקרונית (החוזרת אצל רבים) – לא כל מקרה פרטי מצדיק טיפוס משלו. בדרך כלל, המקרים הפרטיים הם עצמים שונים של אותה המחלקה.

Exercise 2 – Q1

Question: Where should I write the JavaDoc documentation when I write an interface? (at the interface / implementation(s) / both ?)

Answer: only interface.

The contract of the implementation is unknown for most clients (and must follow the contract of the interface).

Nevertheless, if a certain implementation requires from the client less than the original contract (as appears in the interface) it should state that as its precondition

If a certain implementation does more than promised by the original contract (as appears in the interface) it should state that as its postcondition and / or invariant.

Question: Are any two data structures from java.util acceptable

Answer: yes, you may consult the API or any other resources (tutorials, books, etc.)

Question: I don't understand the need of isFull(). Is the following acceptable?:

public boolean isFull() {
  return true; /* Dynamic stack is never full */
 }

Answer: That depends on your implementation. One might not bother to make her stack dynamic resizeable... of course if yours is, it seems fine. 

Question: Can I change the prototype of IStack<T> createStack() such that it will receive a parameter which specifies the type implementation) of the stack?

Answer: can't change but may overload (and don't forget to use mutual calls between the overloaded versions to enforce consistency)

Question: Should the factory be a per-type factory (i.e. generic, depends on <T>) or should the type of the stack be also a parameter to IStack<T> createStack() ?

Answer: A factory should be a per-type factory (i.e. generic). Meaning it is really a StackFactory<T>

Question: How can a per-type factory be a singleton? (If there is one factory per each type…)

Answer: A singleton StackFactory<Product> is good enough for this exercise.

Question: How many columns are in the Fridge?

Answer: pick a number. It may not be dynamic (but use proper constants)

Question: How do I know what column related to a certain product (I guess I shouldn't use 'instance of') ?

Answer: Ue getName() for that purpose (don't use instanceof)

Question: Can you please elaborate the functionality of Product pickProduct(String name) ?

Answer: Get the first product of the column "name".

One possible use of the method might be:

a. call pickProduct

b. check its expiration date:

   b1. if it is ok - you're done

   b2. if it has expired go to a.

Question: Should the method push make sure stack is not empty,
or it's just a pre-condition that shouldn't be checked?

Answer: A method should never check its precondition

Question: Since we can't submit any product classes as .java files,
for testing purposes we should write inner classes in Makolet.java, right?

Answer: No! You should supply some product classes of your own

Question: this simple line won't compile:
IStack<Product>[] shelves = new IStack<Product>[numOfShelves];

with the error:
Cannot create a generic array of IStack<Product>

removing the <> from the line works:
IStack<Product>[] shelves = new IStack[numOfShelves];

but produces the warning:
Type safety: The expression of type IStack[] needs unchecked conversion to
conform to IStack<Product>[]

is there a clean way out of this or should I just add
@SuppressWarnings("unused") ?

Answer: There is no clean way to avoid that. It is an inherent problem with java syntax. You can't create type safe generic arrays. Keep the warning or use SuppressWarnings.

Question: loadFridge method recieves a parameter of type Collection. Can we change it to Collection<Product>?

Answer: yes, you should use Collection<Product>

Exercise 2 – Q2

Question: It says in the exercise that Tree should implement Collection. Are we expected to implement all of:

public Object[] toArray()

public <T> T[] toArray(T[] arg0)

public boolean add(T arg0)

public boolean remove(Object arg0)

public boolean containsAll(Collection<?> arg0)

public boolean addAll(Collection<? extends T> arg0)

public boolean removeAll(Collection<?> arg0 (

public boolean retainAll(Collection<?> arg0 (

public void clear()

etc. ?

Answer: You should implement a minimal interface that would allow you to demonstrate your iterator. The core of this question is not the Tree but its iterator. Tree is a collection but not necessarily a java.util.Collection. NevertheLess it should implement the Interface java.lang.Iterable<T>

Question: Should we implement REMOVE in the iterator?

Answer: At least an empty one (otherwise you can't implement Iterator<T>)

Question: Do you have a typo on page 4 in the code snippet?

public void printTree(Tree<someType> t) {

for (someType elem : t)

System.out.print(elem + " ");

System.out.println("") ;

}

Answer: Yes, it should be elem, of course.

Exercise 3

Question: Can we implement the iterator classes as inner classes of the XSortedSet classes (same .java file)?

Answer: yes

Question: Can we use an iterator() method which does not look like:

/**

             * Returns an Iterator for the elements of this set.

             */

public SortedIterator iterator() {

return new MergedSortedIterator(setA.iterator(), setB.iterator());

            }

     ?

Answer: no. Except for the generic types that should have be added (and should have been there in a first place…), the merged iterator should be based on the iterators of the original sets.

Question: In the API for CompositeSortedSet there is a constructor, but in class you explained there are no constructors for abstract classes.

Answer: interfaces have no constructors. Abstract classes may NOT be instantiated but they MAY have constructor.

Question: How can I compare between T objects?

Answer: you have several options. The simplest one is to make casting to Comparable.

There are also better options. One of them, which we didn't discuss in class yet, is to change SortedSet<T> to be SortedSet<T extends Comparable<T>>. This solution will be also acceptable (but you need to investigate it further).

Question: Should CompositeSortedSet compute {min, max, size, isempty} as MergedSortedSet would have? if so, what is the purpose of the abstract class CompositeSortedSet?

Answer: This is exactly the point of the exercise. Abstract classes should only implement the common behavior of ALL their descendants. Operations that are specific to each subclass should remain abstract. On the other hand I don't see how do { min, max, size, isempty } different.

Are they really depend on the class?...

Question: Should In class ArithmeticSeriesSet, method contains(Integer element) It says that "contains method will return false for any Object which is not of the Integer class." Should I change the method to contains(Object element), and then check the object's class?
(otherwise the compiler just doesn't accept any nonInteger object)

Answer: no, no, no.

I probably should have written: "Elements of ArithmeticSeriesSet are of type Integer, and the compiler should enforce that"

Exercise 4

Question: In question no. 2 : can sum and product be a trenary operation (on three expressions)?

Answer: sum and product are binary. They may be combined to form a ternary expression: eg: sum(sum(literal,literal), literal).

Question: In q.1 when should we have interfaces and when not?

Answer: Interfaces are used to separate the "what" from the "how". Where different implementations of the same services are available, an interface including those services should be used (as we saw in the recitation with the Collection framework). Sometimes interfaces are not necessary. Common sense and experience should be used.

The reader should not be troubled about the lack of experience; by making mistakes she would acquire herself some... :). Again, there is more than one "right" answer - and you should be aware to the implications of your choices.

Exercise 5

Question: Can you please give a link about the Builder Design Pattern? I found some links, but they're all in C++, and not in java

Answer: start with: http://www.patterndepot.com/put/8/JavaPatterns.htm
or
http://www.javacamp.org/designPattern/
or
http://www.mindviewinc.com/downloads/TIPatterns-0.9.zip

or try www.google.com -> "java design patterns" (this is what I did…)

Monopoly part I

Question: what did you mean when you said that "the bank can be stupid"?

Answer: The bank does not need to have any inspiring strategy, such as
creative deals (for example give a player the option of TASHLUMIM). In addition the bank is not a player so it has no motivation of increasing
its income, or winning, so it will always stick to the rules.

If you choose a different behavior for the bank, make it optional, so
it could be turned on/off at runtime.

שאלה: בפרוייקט מונופול שלנו אפשר לממש בנק טיפש. מה הכוונה בטיפש? האם הכוונה היא שיש לו רק כסף אינסופי או שאפשר להתיחס לתשלום של קנס לבנק כסתם הורדת כסף משחקן, ולא ממש העברת הסכום לבנק?

תשובה: שאלה טובה (ומקורית). בנק טיפש הכוונה לבנק בלי אג'נדה. הבנק לא צריך להיות "יצירתי" מבחינת החוקים. לדוגמא: אם שחקן חייב לבנק כסף ואין לו, הבנק לא יכול להציע לשחקן עיסקה
(פריסת תשלומים וכו'). לא כך לגבי שחקנים - המשחק כן אמור לתמוך בעסקאות
יצירתיות בין שחקנים (ע"י מתן ממשק כללי מספיק להגדרת עסקה).
לגבי ההון של הבנק - ההחלטה לא קשורה לעד כמה חכם הבנק. ניתן להחליט כי
לבנק סכום אינסופי (ניתן גם אחרת...)

שאלה: כקו מנחה, הצוות שלנו בפרויקט המונופול מעוניין לגרום למעבר חלק כמה שיותר מהחלק הראשון לחלק השני של הפרויקט. אנחנו נתקלים בדילמות בנוגע לאופן בו נתכנן את זרימת הנתונים בכל הנוגע לקלט ופלט בין התוכנית למשתמש, וזקוקים לייעוצך.

היות ועדיין לא למדנו על תכנות רשת זה מעט בעייתי. אני אישית תכנתי בעבר  ב Winsock ולכן אני מודע לבעיות שעלולות לצוץ. ב Winsock קבלת קלט דרך הרשת מתרחשת דרך טיפול באירוע מיוחד (תכנות מונחה אירועים). זאת בניגוד למשל לקריאת טקסט ממשתמש מקומי; התוכנית עוצרת עד שהטקסט נקלט (תכנות מודולארי רגיל – קריאה לפונקציה שמחזירה ערך(.

לכן העלנו רעיון שגם את החלק הראשון של הפרויקט יבנה באופן שהוא כביכול מונחה אירועים בכל הנוגע לקלט ופלט. למרות שזה יגרום לקוד להראות פחות קריא, המעבר הגורלי למימוש רשת וממשק גרפי יעבור בהרבה יותר אלגנטיות.

לכן, השאלה שלי היא: האם אכן כזה יהיה ממשק ספריית הרשת מבחינת תוכנת ה Server – כלומר, האם כמו Winsock ספריית הרשת שנלמד תעבוד באופן מונחה אירועים. אם כן, אז נתכונן בהתאם כבר עכשיו. אחרת, אם התקשורת פועלת באופן מודולארי כמו מין Web-Service, אזי נרגיש די טיפשים אם נטרח עכשיו לשווא.

תשובה: לא ולא. קריאת קלט מהמשתמש בכל שפות התכנות:
scanf בשפת C
cin>> בשפת ++C
System.in.read()בשפת Java

מוגדרות כ blocking כלומר ממתינות להגעת קלט, ממש כמו קריאת קלט מהרשת (רשת, מקלדת, קובץ ואחרים הם כולם streams).

מכיוון שההפשטה הבסיסית כבר נעשתה ע"י ספריות java (ומערכת ההפעלה) – אין באמת צורך "לתכנן" יותר מדי.

ככלל, אין צורך להכליל מקרה כל עוד לא נתקלתם בשני מופעים שלו. כל החשיבה מראש הזאת היא עקרה. נשמע מוזר לשמוע את זה ממרצה לתוכנה (אחרי שאתם רק שומעים מאיתנו "זה לא מספיק כללי") אבל זו המציאות. הכללה באה לפתור שכפול קוד או ליצור הפשטה ולא כדי לפתור בעיות דמיוניות. כלל ה- KISS נשמר.

איפה כן כדאי לשים לב? בשימוש בפונקציות הקלט (פלט) עצמן (System.out.xxx, System.in.xxx ) אף על פי שגם הן מאוד דומות לפונקציות קלט/פלט מהרשת.

לגבי מימוש התקשורת בחלק השני של הפרוייקט – דיה לצרה בשעתה.

שאלה: האם צריך להגיש גם תדפיסים של הקוד ביום שישי?

תשובה: אין צורך להדפיס את הקוד אולם יש צורך להביא אותו (CD/DiskOnKey/WEB). במהלך ההצגה נעבור על חלקים נבחרים בקוד.

שאלה: היכן מציגים את הפרוייקט?

תשובה: הפרוייקט יוצג על אחד המחשבים במעבדת התוכנה - בבניין וולפסון להנדסת תוכנה חדר 209 (הוראות הגעה באתר הקורס)