Gregory M. Kapfhammer

Kristen Walcott- Lab 6

1. Description of the Flyweight design pattern and the Singleton design pattern

The Flyweight design pattern prevents multiple instances of identical objects. By preventing the duplication, you can greatly reduce memory storage requirements. The term flyweight refers to shared objects. To use this design pattern, the objects must be immutable since the objects are all shared. If they were mutable, changes could be made to one object that would then be visible to the others. In order to avoid duplicate objects, we keep track of already existing objects using a table. This table can be hidden or visible to users, depending on the situation. When a new object is requested, a method checks to see whether the desired object already exists in the table of not. If the object already exists, it returns the pre-existing object. Otherwise it creates a new object.

In the case of this lab, the method also checks to see if the identifier has the properties assigned to it previously. For example, if the desired identifier is a reserved word, but the one already in the table is non-reserved, an exception is thrown. In our IdentifierTable class, we only want one copy of each Identifier, so the Flyweight design pattern is kind of appropriate.

The singleton design pattern ensures that only one effective instance of a class is created globally. Using a singleton can improve performance and eliminate errors in code. In order to enforce the object to be a singleton, the constructor must be made private and access the object through a static method. The method returns the object, or creates it if it is the first time it has been requested.
This can be good as seen in the case of our example: if there were more than one IdentifierTable, we would not be able to guarantee just one object for a unique identifier.

Flyweights should be used when there is a sufficiently large amount of sharing because there is extra complexity in having to maintain the related table. In the case of this lab, I'm not sure that the use of the flyweight pattern is really jusitified. Then again, if this were being used in a large scale project like a search engine or a compiler
of some sort, it could be useful. Singletons also can be useful in the right situations, but it seems like the structure is more undesirable than anything because it increases dependencies. If it forces you to make the entire class static to use everything properly, that is even more undesirable. Thus, the singleton design pattern increases dependencies and makes code much more specific and less reusible or expandable.

2. Challenges that would be faced with testing classes that adhere to the Singleton design pattern.
Before I actually read the end of the assignment, I began trying to force the JUnit test suite to conform to the Singleton design pattern. Instead of creating an instance of the IdentifierTable class, you have to set the Identifier to IdentifierTable.getTable(). If the test suite includes more than one test, using the Singleton design requires the use of cleanup functions after each test. I originally thought that this could be done using the tearDown method from TestCase. In tearDown, the table could be set back to null so it could be recreated.

However, this doesn't change the table in IdentifierTable, only the varible in TestIdentifierTable. Thus, there would have to be some kind of static remove() method added to IdentifierTable which can be called in order to do cleanup. Right now, that method does not exist.

3. Pitfalls, Problems, Revelations
I had a little bit of trouble with the packages just because I kept trying to compile the classes from the wrong folder. Once I remembered to change folders it was fine.
IdentifierTable, Identifier, and WrongKindOfIdentifierException were all in a folder called identifier and were in the package identifier. The test suites were in the folder above that, Lab 6. The test suites had to import the identifier package in order to use the classes.

For quick easy reference/pasting:
Setting classpath for junit and log4j-
[walcott@aldenv103 Lab6]$ setenv CLASSPATH /home/walcott/CS290/JUnit/junit.jar:/home/walcott/CS290/Lab4/log4j-1.2.8.jar:/home/walcott/:.
Running program with log4j included-
[walcott@aldenv103 Lab6]$ java -Didstuff.logging=idstuff_log.lcf TestIdentifierTable

---

Things to be handed in:
1) IdentifierTable.java (Part of the Flyweight design pattern)
2) Identitifer.java (Part of the Flyweight design pattern)
3) WrongKindOfIdentitfierException.java
4) TestIdentifierTable.java abd TestIdentifier.java
5) IdentifierTable.java (Adheres to Singleton design pattern)
6) Output of execution of the test suites
a) Verbose logging enabled
b) No logging

Kristen Walcott

---

Links to this Page

• Kristen Walcott last edited on 8 December 2004 at 8:24 pm by acs-24-144-201-80.zoominternet.net
• Lab 6 Notebooks last edited on 9 December 2004 at 3:21 pm by aldenv28.allegheny.edu