Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Jeff Higgins Newsgroups: comp.lang.java.programmer Subject: Re: Aspect questions? Date: Mon, 27 Feb 2012 14:05:51 -0500 Organization: A noiseless patient Spider Lines: 93 Message-ID: References: <4f4a6b1d$0$290$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 27 Feb 2012 19:05:47 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="BSKXKq4dV+7jFlM4JDctyw"; logging-data="5668"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ZN2TR7K82XxOr8SQd7ezCV4Tig/nkOsM=" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20120207 Icedove/3.0.11 In-Reply-To: Cancel-Lock: sha1:PaSnu9W+5W8AkxurNnySYAY6EEw= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:12441 On 02/27/2012 01:18 PM, Jeff Higgins wrote: > On 02/27/2012 12:36 PM, Novice wrote: >> At least you know what you're doing! I have perfectionist tendencies >> without really being sure what I'm doing; try finding perfection when you >> don't really have a clear picture of what it is! :-) > > Look at other projects, lots of them. > >> I don't really see packages as that big a deal though. Whether I import >> one or five to twenty-five in a given class doesn't seem that important >> though. More packages probably makes the Javadocs more impressive looking >> at first glance but if the underlying code doesn't make sense, then it's >> all nonsense anyways.... >> > You need to develop your own sense of order and beauty, no one here can > give you one. > > Look at the Eclipse API Specification: Do you find it orderly and beauteous? Why? Why not? An exercise: Write a package description and specification for each of the packages in your project. Use the Eclipse API Specification as a template. Package org.eclipse.core.commands Description Application programming interfaces for commands and handlers. Package Specification This package provides API and implementation classes to define abstract pieces of functionality. These pieces of functionality are intended to provide a common way for plug-ins and the user interface to communicate potential behaviour. This package is designed so that its elements can be public and dynamic. That is, elements in this package can appear and disappear over the life of the application. Package org.eclipse.core.commands.common Description Application programming interfaces for common base classes. Package Specification This package provides some common base classes and exceptions that are used in one or more packages elsewhere. Nothing in this package is intended to be directly subclassed, or used. The code here only supports code in other packages. Package org.eclipse.core.commands.contexts Description Application programming interfaces for contexts. Package Specification This package provides API and implementation classes to define abstract representations of application state. These representations of application state can be used as an abstraction of the event-listener model -- where different sections of code do not (or cannot) refer to each directly. This package is designed so that its elements can be public and dynamic. That is, elements in this package can appear and disappear over the life of the application. Package org.eclipse.core.commands.operations Description Classes for the creation of undoable operations which can be added to an operations history and later be undone and redone. Package Specification An undoable operation is a unit of work that can be executed, undone, and redone. Operations can be added to an operation history so that they can later be undone and redone according to the undo model for an application. Operations may be assigned one or more undo contexts which can be used to filter the available operations for undo or redo in the operation history. Clients may choose to provide undo and redo function for all operations in a history, or only for a particular undo context in that history. Operation histories may be configured with an operation approver so that applications can enforce any desired undo model, such as strict linear (LIFO) undo. This package provides the definition and a basic implementation for operations, undo contexts, histories, and operation approvers.