没有集合库的HashTable

时间:2014-03-06 06:49:10

标签: java arrays oop hashmap hashtable

我正在尝试创建一个基本的文件系统。我不能使用Collections库。此文件系统存储两种类型的数据FilesDirectories。类型FileDirectory都是抽象类型Entry的子类。

到目前为止我的设计

我的哈希函数是取Entry的名称,并将名称中的每个字符转换为一个整数,并将它们加起来为一个值。接下来用数组的大小修改值以确定它的放置位置

protected static int hashFunction(String entryName) {
        char[] a = entryName.toCharArray();
        int sum = 0;
        // convert String to integer Value
        for (char b : a) {
            sum += (int) b;
        }
        int hashValue = sum % hashTableKey;
        return hashValue;
    }

我遇到的问题是设计哈希表。目前,一旦哈希函数计算该值,我将EntryentryName)的名称存储在相对于hashVaue的数组中。我将实际对象存储在另一个相同大小的数组中以保存这些对象。这些对象的存储与包含对象名称的数组中的相应名称具有相同的索引。

*对象可以是文件或目录

| "obj1" | None | "obj3" | None | None | None | "obj2" | None |

| obj1 | None | obj3 | None | None | None | obj2 | None |

不确定这是否是使用哈希表实现文件系统的好方法。我选择哈希表的原因是由于O(1)查找。但是它有很大的空间要求。特别是我实现它的方式。如果有更好的方法来实现文件系统,请告诉我!我对这些想法很开心!!

1 个答案:

答案 0 :(得分:1)

我认为你不应该拥有另一个数组,你可以将实际对象存储在第一个数组中,因为实体将知道它的名称,因此在选择元素时很容易进行健全检查。

虽然我认为设计缺陷,除非我误解了某些内容,但是当两个文件具有相同的哈希码时,你实际上容易出错,因为你只能存储尽可能多的密钥在您的哈希表中。

通常解决的问题是,不应该有一个字符串和实体数组,你应该有一个LinkedList数组(好吧,你的链接列表的实现,因为你不能使用集合)并将实体存储在列表中,这将使你的性能依赖于你的哈希函数有多好,但这也会减少所需的空间,尽管不是很多。这就是Java的哈希映射实际上或多或少的效果。

就个人而言,我真的不喜欢依赖同一个索引上具有相同对象的两个数组,这只是非常容易出错。