Jenny Harlow

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
Line 2: Line 2:
 
----
 
----
  
= Project =
+
== Project ==
Redesigning [part of] the Java Collections Framework
+
Designing a simple collections framework
  
== Introduction ==
+
=== Introduction ===
This project will attempt to redesign part of the [http://download.oracle.com/javase/tutorial/collections/index.html Java Collections Framework] from the point of view of 'if we were starting again, what might we do'.  The whole framework is huge, and includes many specialised features such as the [http://download-llnw.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/package-summary.html java.util.concurrent] classesThis project will focus on what we might consider to be the main everyday usage collections - the ones that come into almost everything we might want to write: lists, sets, maps.
+
In COSC324 Wal emphasised the use of Collections for efficient programming. He pointed out some of the ways in which the Java Collections Framework uses design patterns (wrappers, [[Iterator|iterators]], [[Factory Method|factory methods]]), but also some of the glaring Arrghghgs (the OO term seems to be [[antipatterns]]) that there seem to be in the current design. Naturally we all nodded wisely and agreed that it is just terrible ...  It's easy to criticise, but just how easy is it to design a collections suite? 
  
== Background ==
+
This project will attempt to redesign part of the [http://download.oracle.com/javase/tutorial/collections/index.html Java Collections Framework] from the point of view of 'if we were starting again, what might we do'.  The whole framework is huge, and includes many specialised features such as the [http://download-llnw.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/package-summary.html java.util.concurrent] classesThis project will focus on what we might consider to be the main everyday-usage collections - the ones that come into almost everything we might want to write: lists, sets, maps.
In COSC324 Wal emphasised the use of Collections for efficient programming.  He pointed out some of the ways in which the Java Collections Framework uses design patterns (wrappers, [[Iterator|iterators]], [[Factory Method|factory methods]]), but also some of the glaring Arrghghgs (the OO term seems to be [[antipatterns]]) that there seem to be in the current design. Naturally we all nodded wisely and agreed that it is just terrible ...  It's easy to criticise - can I do any better?
+
  
= Design Study =
+
=== The Java Collection framework ===
  
== Requirements ==
+
==== A brief overview of the Java Collections framework ====
 +
 
 +
==== Critique of the Java Collections framework ====
 +
 
 +
===== The good ...=====
 +
===== The bad ... =====
 +
===== And the ugly ... =====
 +
 
 +
 
 +
 
 +
=== Design study ===
 +
 
 +
==== Aims ====
 
My aim is to create a design for a collections framework that includes lists, sets and maps and provides equivalent functionality to the existing [http://download.oracle.com/javase/tutorial/collections/implementations/index.html|general-purpose implementations].   
 
My aim is to create a design for a collections framework that includes lists, sets and maps and provides equivalent functionality to the existing [http://download.oracle.com/javase/tutorial/collections/implementations/index.html|general-purpose implementations].   
  
My initial thinking about this project made me realise that a major issue for Collections is contracts:  Collections are for other programmers to use and so using and abiding by [[Design by contract|design by contract]] has to be just as important, if not more so, as conspicuous display of [[Gang of Four 1995|GoF]]-authorised design patterns.  Am I claiming the design by contract is more important here than in some of the other projects?  No, but I am saying that it is very very relevant when designing a framework whose sole purpose is to provide objects to be used by clients. 
+
==== Design issues ====
  
== Optional extras ==
+
My initial thinking about this project made me realise that a major issue for Collections is contracts:  Collections are for other programmers to use and so using and abiding by [[Design by contract|design by contract]] has to be just as important, if not more so, as conspicuous display of [[Gang of Four 1995|GoF]]-authorised design patterns.  Am I claiming the design by contract is more important here than in some of the other projects?  No, but I am saying that it is very very relevant when designing a framework whose sole purpose is to provide objects to be used by clients.  
If I have time I am interested in the idea of a performance test suite for collections, running some standard tests and providing a summary of results.
+
  
 +
all things to all men 
  
 +
=== Optional extras ===
 +
If I have time I am interested in the idea of a performance test suite for collections, running some standard tests and providing a summary of results.
  
  
== Constraints ==
 
  
== Review of the Java Collections Framework ==
+
 
=== The good ...===
+
=== Constraints ===
=== The bad ... ===
+
=== And the ugly ... ===
+
  
  
Line 37: Line 47:
 
=== Diagram ===
 
=== Diagram ===
  
 
=== Description of Classes ===
 
  
 
== Design Critique ==
 
== Design Critique ==
Line 45: Line 53:
  
  
== Design Improvements ==
+
=== Design Improvements ===
  
 
I have set up a separate page [[Jenny's Design scratch-pad|design scratch-pad]] for thoughts-in-progress that are too open-ended to  have made it here yet.
 
I have set up a separate page [[Jenny's Design scratch-pad|design scratch-pad]] for thoughts-in-progress that are too open-ended to  have made it here yet.
  
= Files =
+
== Files ==
 
+
 
+
= Acknowledgements =
+
 
+
--[[User:Jenny Harlow|Jenny Harlow]] 05:41, 10 August 2010 (UTC)
+

Revision as of 22:04, 17 August 2010

Navigation shortcuts: Wiki users:Jenny Harlow


Contents

Project

Designing a simple collections framework

Introduction

In COSC324 Wal emphasised the use of Collections for efficient programming. He pointed out some of the ways in which the Java Collections Framework uses design patterns (wrappers, iterators, factory methods), but also some of the glaring Arrghghgs (the OO term seems to be antipatterns) that there seem to be in the current design. Naturally we all nodded wisely and agreed that it is just terrible ... It's easy to criticise, but just how easy is it to design a collections suite?

This project will attempt to redesign part of the Java Collections Framework from the point of view of 'if we were starting again, what might we do'. The whole framework is huge, and includes many specialised features such as the java.util.concurrent classes. This project will focus on what we might consider to be the main everyday-usage collections - the ones that come into almost everything we might want to write: lists, sets, maps.

The Java Collection framework

A brief overview of the Java Collections framework

Critique of the Java Collections framework

The good ...
The bad ...
And the ugly ...

Design study

Aims

My aim is to create a design for a collections framework that includes lists, sets and maps and provides equivalent functionality to the existing implementations.

Design issues

My initial thinking about this project made me realise that a major issue for Collections is contracts: Collections are for other programmers to use and so using and abiding by design by contract has to be just as important, if not more so, as conspicuous display of GoF-authorised design patterns. Am I claiming the design by contract is more important here than in some of the other projects? No, but I am saying that it is very very relevant when designing a framework whose sole purpose is to provide objects to be used by clients.

all things to all men

Optional extras

If I have time I am interested in the idea of a performance test suite for collections, running some standard tests and providing a summary of results.



Constraints

Initial Design

Diagram

Design Critique

Design Improvements

I have set up a separate page design scratch-pad for thoughts-in-progress that are too open-ended to have made it here yet.

Files

Personal tools