|
Unidirectional object relationships
Implementing object relationships where one of the two multiplicities is singular (either one-to-one or one-to-many relationships) is simple once you understand the fundamentals.
|
|
OO Design Process: The object primer
Developing software is no easy task, but don't be daunted. This article will get you started by discussing the complexity of object-oriented development and showing you how to prioritize your efforts. In the end, you will have gone through the elemental software development process.
|
|
An overview of object relationships
Objects have associations to, or relationships with, other objects. Understanding the nuances of relationships in object modeling is the first step to understanding how to implement them in your Java source code.
|
|
Implementing one-to-many object relationships
Implementing a one-to-many object relationship is reasonably straightforward once you understand the fundamentals.
|
|
Implementing many-to-many object relationships
In Java, a many-to-many object relationship is implemented via a combination of collections and operations to manipulate those collections.
|
|
Integrating components
Judith M. Myerson delivers an overview of the promises (frameworks as reusable mechanisms, middleware that provides request brokers for horizontal infrastructure services and component connector mechanisms, component-based software engineering, and Web engineering) and problems (firewalls making user collaboration difficult, inadequate risk analysis, and the non-availability of components) to providing component-integration benefits to the wireless world.
|
|
Rules and Patterns for Session Facades
In the past couple of years Enterprise JavaBeans™ (EJBs) have really started to make an impact in the Java™ object design space. During this time, one of the most common EJB patterns that we have seen employed is the notion of a Session Facade.
|
|
Grady Booch polishes his crystal ball
Grady Booch spends his time pondering how to improve software development. As such, he thinks about how current trends -- UML, aspect-oriented programming, Web services, and so on -- will evolve into tomorrow's development environments. Most importantly, Grady believes that we solve the complexity problem by continually raising the level of abstraction. Find out what Grady thinks about these and other issues in this exclusive interview with developerWorks Editor-in-Chief Michael O'Connell.
|
|
Improve modularity with aspect-oriented programming
Aspect-oriented programming (AOP) is a new programming technique that allows programmers to modularize crosscutting concerns (behavior that cuts across the typical divisions of responsibility, such as logging). AOP introduces aspects, which encapsulate behaviors that affect multiple classes into reusable modules. With the recent release of AspectJ by Xerox PARC,
|
|
XMI and UML combine to drive product development
Countless organizations rely on UML (Unified Modeling Language) in the software development process. But software to manage UML itself has a well-earned reputation for being inflexible and difficult. This article describes how the Danish development house Ideogramic ApS extended XMI (an XML specification targeted at such metadata as UML), and explores both the benefits and limitations of "XMLization."
|
|
Advanced DAO programming
J2EE developers use the Data Access Object (DAO) design pattern to separate low-level data access logic from high-level business logic. Implementing the DAO pattern involves more than just writing data access code. In this article, Java developer Sean C. Sullivan discusses three often overlooked aspects of DAO programming: transaction demarcation, exception handling, and logging.
|
|
A stepped approach to J2EE testing with SDAO
The Data Access Object pattern has become a standard part of the J2EE developer's arsenal. What most developers don't know is that one of its variations allows for much easier testing. Simulated data access objects bring together the best of DAO, mock objects, and layered testing, letting you simultaneously improve both your testing results and your overall development metho
|
|
Demystifying Extreme Programming: "XP distilled" revisited, Part 1
Object-oriented programming in the Java language has become immensely popular. It is even revolutionizing software development to some degree. Still, recent studies show that half of all software development projects are late, and one-third are over budget. The problem isn't the technology; it's the way we develop software
|
|
Applying packages on UML diagrams
Read these tips on using packages to simplify and organize your UML software diagrams. This article was modified from Chapters 3 and 6 of The Object Primer 2nd Edition.
|
|
Deriving Web services from UML models, Part 1: Establishing the process
By following a few straightforward steps, you can organize your object-oriented applications into packages of cohesive functionality that are accessible via Web services. In this first installment of a series, Scott W. Ambler outlines a road map for a quick and easy transition.
|
|
Deriving Web services from UML models, Part 2
The first task when identifying Web services is to conceptually simplify your object design. That way, as you move forward through the process, you only need to focus on its critical aspects.
|
|
Deriving Web services from UML models, Part 3: Identifying domain packages
Before you identify potential Web services for your application, you must first identify cohesive packages of functionality that you wish to access via those services. In the third installment of this series, Scott W. Ambler shows you how to organize your application to make it a better Web service.
|
|
Deriving Web services from UML models, Part 4: Defining Web services
Web services can be offered by cohesive collections of classes called domain packages in such a way as to provide significant functionality through a small number of services. In the final installment of this series, Scott W. Ambler shows you how to complete the transformation of your object-oriented application into a suite of Web services.
|
|
Development of Federal Enterprise Architecture Framework using the Rational Unified Process and the UML
This paper explores how RUP and the UML can be used to build and manage Enterprise Architectures. Specifically, it examines the Federal Enterprise Architecture Framework (FEAF) level IV matrix and discusses how RUP facilitates capturing various FEAF models.
|
|
Design XML schemas using UML
Unified Modeling Language (UML) is an industry standard that is used in modeling business concepts when building software systems in an object-oriented manner. Recently, XML has gained ground in becoming a key enabler of these systems in terms of transport of information and commands. XML schemas, which are used to define and constrain the nature of XML exchanged, have consequently come into the limelight. This article discusses the use of UML in designing XML schemas and gives a hands-on approach for using the UML framework to create your XML vocabularies.
|
|
From UML to BPEL
The Business Process Execution Language for Web Services (BPEL4WS or BPEL for short) is an XML-based standard for defining how you can combine Web services to implement business processes. It builds upon the Web Services Definition Language (WSDL) and XML Schema Definition (XSD
|
|
How to draw UML activity diagrams
UML activity diagrams document the logic of a single operation or method, a single use case, or the flow of logic of a business process. To create a UML activity diagram, you should iteratively perform the following steps, modified from Chapter 6 of The Object Primer 2nd Edition.
|
|
Relational modeling with UML
This whitepaper explains the basic concepts behind relational modeling, how it applies to databases, and how it is implemented using the Unified Modeling Language (UML). In addition, it identifies differences between Entity Relationship (ER) modeling and relational modeling
|
|
Entity relationship modeling with UML
Entity Relationship Modeling (ER) defines the methodology often used by database designers to gather requirements and define the architecture of database systems. This white paper defines the core concepts of ER modeling and explains how UML can be used by development teams to develop ER models.
|
|
Using UML for modeling complex real-time systems
This paper describes a set of constructs that facilitate the design of software architectures for embedded development, with an emphasis on how the extensibility mechanisms of UML can be applied to work in this domain.
|
|
Turning clockwise: Using UML in the real-time domain
UML is particularly well-suited to designing real-time software, because of of timeliness constraints and the need to contend with the daunting complexity of the physical world. This article describes some UML-based techniques that can be used to overcome these challenges.
|
|
UML for Database Design
The Unified Modeling Language (UML), the standard graphical notation for modeling business and software application needs, has emerged as an effective modeling tool for database design. When used as a common modeling language for the many facets of system development, the UML can serve as a unifying framework that facilitates the integration of database models with the rest of a system design.
|
|
Database Design from Requirements to Implementation
|
|
Database Design Models — the UML Profile for Database Design
|
|
Effective business modeling with UML: Describing business use cases and realizations
This will be of interest to those organizations that are thinking about applying the UML Business Modeling Profile. It walks through an example case that models the acquisition process within an IT department responsible for managing outsourced development.
|
|
Developing embedded and mobile Java technology-based applications using UML
The head buyer for a Fortune 500 chemical company is on site in South America with his supplier, about to order millions of dollars worth of solvent at a reduced price, but before signing the deal he uses a software application embedded into his PDA to check his global inventory. He sees that as a result of an acquisition that took place hours ago on the other side of the world, his company now has an excess of the solvent. He cancels the deal, saving his company millions.
|
|
Introduction to the Unified Modeling Language
Before joining Rational, in 1993, I worked for another well-known technology company, only there I was using OMT (the methodology developed by Jim Rumbaugh and company
|
|
Unifying development teams with UML
There is a fundamental paradox at play in contemporary software development. On the one hand, organizations are faced with the demand for faster time to market; on the other hand, these same organizations are under pressure to deliver systems with higher quality at lower cost. Keeping a balance between these two forces is quite hard: rush a software system to market, and its quality will undoubtedly suffer; focus only on quality, and you may still fail because it took you too long to release your system to its users.
|
|
Introduction to the Unified Modeling Language
Before joining Rational, in 1993, I worked for another well-known technology company, only there I was using OMT (the methodology developed by Jim Rumbaugh and company
|
|
Quality software and the Unified Modeling Language
Worldwide, there is an insatiable demand for software. On the one hand, that's great news. These are exciting times for the professional software developer, for this is still largely an era of innocence and unbounded opportunity
|
|
Use case modeling tips
This article presents a collection of tips and techniques to improve the quality of system use-case models. This article is adapted from Chapter 6 of The Object Primer 2nd Edition.
|
|
When worlds collide
It should come as no great surprise, but in the presence of the Web, the organization of your development team is incrementally more complex.
|
|
Using Rational Rose: Some tips & tricks
Here, in no particular order, are two shortcuts and ways to work with Rose.
|
|
Designing for concurrency and distribution with Rational Rose RealTime
Real-time embedded systems (such as for e-devices) can use active objects to address problems caused by concurrent threads and the need to make objects easily distributable. This paper explains how.
|
|
History-making components
This timeline explores some of the key events of object-oriented programming and components in the last 50 years in the greater context of general computing history.
|
|
Modeling the enterprise data architecture
Unlike the simplistic models in books and training courses, a real enterprise has a very complicated data architecture. Most of the data will be held in large legacy or package systems, for which the details of data structure may be unknown.
|
|
Java Modeling: A UML workbook, Part 1
Unlike the simplistic models in books and training courses, a real enterprise has a very complicated data architecture. Most of the data will be held in large legacy or package systems, for which the details of data structure may be unknown.
|
|
Java Modeling: A UML workbook, Part 2
Granville continues his discussion of the Unified Modeling Language and sequence diagramming. He examines the role of conditional logic in sequence diagramming and discusses why you might choose to include or exclude conditions and loops from a diagram. Granville also describes the two forms of sequence diagram -- generic and instance -- and explains their respective applications in the development cycle.
|
|
Java Modeling: A UML workbook, Part 3
In this installment of Java Modeling, Granville leads you into the gray zone between modeling and method, with a look at requirements gathering via use case modeling. In particular, he focuses on the relationship between user interfaces, system interfaces, and use case descriptions. While tempting to do so, it is generally considered bad form to include user interface logic in a use case.
|
|
Java modeling: A UML workbook, Part 4
After a short hiatus, Granville Miller re-opens the UML workbook for an in-depth discussion of one of the fundamental components of the use case diagram: the actor. The actor is not only essential in UML modeling, it can also play an important role in creating Java applications and may even suggest patterns in J2EE application design
|
|
Java modeling: Holonic software development, Part 1
Granville Miller temporarily abandons the topic of requirements gathering for one more compelling: holonic software development. Find out how this method complements and extends the tenets of the agile development movement, and how its emergence into mainstream development circles may alter the education of software developers, as well as the practice of software development.
|
|
Java Modeling: Holonic software development, Part 2
Granville Miller continues his discussion of holonic software development, with a conceptual overview of requirements gathering. Find out how the four most common requirements gathering processes -- features, user stories, use cases, and the traditional software requirements specification -- fit into the larger context of an agile software development process. Share your thoughts on this article with the author and other readers in the discussion forum by clicking Discuss at the top or bottom of the article.
|
|
UML sequence diagramming with style
Try these tips for creating effective UML sequence diagrams. This article was adapted from Chapter 6 of The Object Primer 2nd Editio
|
|
Documenting a use case
Scott Ambler explains the difference between an essential use case and a system use case, and offers suggestions on how to document either (with a focus on the latter). This article is modified from Chapter 3 of The Object Primer 2nd Edition.
|
|
Overcoming the object-data divide on your EJB project
You can overcome the object-data divide on your EJB project by admitting that the problem exists, recognizing that your software should be based on actual requirements, and recognizing that data professionals can add value on an EJB project.
|
|
The object-data divide and EJB
The "object-data" divide is the gap in understanding between object-oriented and data-oriented developers. Read about how it came into being and how it manifests itself in this week's tip.
|
|
Mapping objects to relational databases
Why is mapping objects to relational databases an issue for modern developers? For one thing, object technology, such as Java technology, is the most common environment applied for the development of new software systems. Also, relational databases are still the preferred approach for storage of persistent information and are likely to remain so for quite some time. Read on to see how you'll put this skill to use.
|
|
Is Enterprise JavaBeans (EJB) technology for you?
Although EJB technology is one of the leading platforms, along with DCOM and CORBA, for the development of mission-critical applications, it isn't the best fit for every project. This tip describes the factors that you want to consider when determining whether EJB technology is the right option for you.
|
|
Why Are Use Cases So Painful?
IT organizations continually struggle to assure that developed software meets its specified requirements. But how can these requirements be discovered, captured, and communicated most effectively? With the advent of use cases six years ago, a solution seemed close at hand. Although use cases have been assimilated into the authoritative Unified Modeling Language (UML), many organizations are finding that their promise is elusive. While use cases were intended to be simple and straightforward, many IT organizations are finding that identifying and gathering project requirements through use cases is painful, that they are difficult to manage, and difficult to understand.
|
|
The OO design process: Getting started
Welcome to the first installment of this online class. My intent with this column is to provide a detailed experience in the object-oriented (OO) design and development process by actually having you do it. This column is more of a journey than an event, as it will take months to get through the entire process. We'll start out with requirements gathering, move through analysis to design, then do a Java implementation of that design. When we're finished, you'll have a complete case history of an OO program, literally from start to finish. I'll talk a lot about the underlying theory, but the central focus will be real examples of how that theory is applied.
|
|
The Process
|
|
Modeling alternate courses in sequence diagrams
This introduction for effectively modeling the alternate course of action within a use case was adapted from Chapter 6 of The Object Primer 2nd Edition.
|
|
The OO design process: Use cases applied, Part 1
In this month's article I continue from last month's article on use-case planning by starting to fill out the use-case template for our first(Depositing funds) use case. I've not just filled in the template, but also provided extensive comments about my thought processes as I was working.
|
|
The OO design process: Use cases applied, Part 2
This article continues my series on the OO design process. The first seven parts have covered planning stages from the initial design, through the refinement of the problem statement and the beginning of our work on use cases. This month, I wrap up use cases before turning, next month, to the user interface
|
|
The OO design process: Use-case planning
In my last column, I introduced the notion of a formal use-case presentation. Use cases will be covered in the next several installments of this column. They are a complex topic, and there is a lot of material to cover, so we'll take our time and look at the issues thoroughly. This month we focus on how to decide which use cases to pursue, and other things we need to keep in mind as we plan our use cases.
|
|
Refactoring for everyone
Eclipse provides a powerful set of automated refactorings that, among other things, let you rename Java elements, move classes and packages, create interfaces from concrete classes, turn nested classes into top-level classes, and extract a new method from sections of code in an old method. Becoming familiar with Eclipse's refactoring tools is a good way to improve your productivity. This survey of Eclipse's refactoring features, with examples, demonstrates how and why to use each.
|
|
Refactoring with Eclipse
Object oriented developers recognize the value of refactoring working code. Until recently good tools have not been available. At OOPSLA 2001 in Tampa, Florida, OTI showed their new open source IDE that features Refactoring support.
|
|
Java design patterns 101
Design patterns capture the experience of expert software developers and present common recurring problems, their solutions, and the consequences of those solutions in methodical way. This tutorial explains why patterns are useful and important for object-oriented design and development, and how patterns are documented, categorized, and cataloged. It also discusses when patterns should be used and provides examples of important patterns and how they are implemented.
|
|
Java design patterns 201
Design patterns extend far beyond those described by the famous Gang of Four. In this tutorial, you will find out just how much. Veteran developer Paul Monday begins his discussion by exploring resources that newcomers to the study of design patterns often miss. Then he uses design patterns from these resources to implement a simple application. Finally, he switches his focus to how design patterns can help you to better understand software design and guides you through the reverse-engineering of a piece of technology, focusing on how it works from the perspective of patterns.
|
|
Diagnosing Java code: Assertions and temporal logic in Java programming
Although traditional assertions can increase the amount of checking that can be done over Java code, there are many checks you just can't perform with them. One way to fill this gap is with "temporal logic," a formalism used to describe how a program state will change over time. In this article, Eric Allen discusses assertions, introduces temporal logic, and describes a tool for processing temporal logic assertions in your programs
|
|
Accessors increase robustness of Java code
Scott Ambler explains how to use accessors, and why their use is one of the most important standards your organization can enforce. This article is modified from Chapter 8 of The Object Primer 2nd Edition.
|
|
Analyzing XML schemas with the Schema Infoset Model
As the use of schemas grows, the need for tools to manipulate schemas grows. The new Schema Infoset Model provides a complete modeling of schemas themselves, including the concrete representations as well as the abstract relationships within a schema or a set of schemas. This article will show some of the power of this library to easily query the model of a schema for detailed information about it; we could also update the schema to fix any problems found and write the schema back out.
|
|
Modeling essential use cases
Essential modeling is a fundamental aspect of usage-centered designs. This week Scott Ambler presents some background and suggestions for developing essential use case models.
|
|
OO design process: Use cases, an introduction
In previous articles, we've refined the problem statement and mocked-up our educational software. In this article we'll look at use-case analysis.
|
|
Member function visibility in Java programs
The visibility of a Java member function defines a Java object's level of access to it. My experience has been that the choice of visibility is an important design decision as well as an important implementation decision because it is one way to reduce the coupling within your system. This week's topic is modified from Chapters 7 and 8 of The Object Primer 2nd Edition.
|
|
Member function visibility in Java programs
The visibility of a Java member function defines a Java object's level of access to it. My experience has been that the choice of visibility is an important design decision as well as an important implementation decision because it is one way to reduce the coupling within your system. This week's topic is modified from Chapters 7 and 8 of The Object Primer 2nd Edition.
|
|
Effective field visibility in Java programs
Fields, also known as attributes or member attributes, are the data aspects of objects. A field's visibility defines the level of access to it by Java objects. This week's discussion, modified from Chapters 7 and 8 of The Object Primer 2nd Edition, focuses on the types of field visibility, how to implement fields, and how to access them.
|
|
Rights and responsibilities of project stakeholders
Project stakeholders have rights that must be respected by software developers. Yet at the same time, they also have a collection of responsibilities that they must fulfill to make software development successful.
|
|
Active stakeholder participation
To succeed, your project team needs the active participation of a wide range of people, including users, management, and other software pro
|
|
Diagnosing Java Code: The Fictitious Implementation bug pattern, Part 1
The Java language is free from many of the problems endemic to languages that support multiple inheritance -- in part because it restricts the specification of interface invariants to type signatures. But that restriction can combine with poor documentation to create problems: if you make incorrect assumptions about how an interface will be implemented, you may encounter frustrating bugs at run time.
|
|
Diagnosing Java code: Unit tests and automated code analysis working together
Unit testing and static analysis are often seen as unrelated ways to help ensure the correctness of a program. This article examines the relationship between these two methods and covers how the tools that form the working backbone of each method can be used to leverage one another to mutual advantage.
|
|
Diagnosing Java Code: The Dangling Composite bug pattern
One of the most commonly recurring (and most complained about) bugs in Java programming is the null-pointer exception. Tracking down the cause of one of these bugs can truly make you question your career decision.
|
|
Bug patterns: An introduction
Welcome to Diagnosing Java Code, a new bi-weekly column that focuses on Java solutions to keep you on track with your daily programming efforts. This premier article introduces the notion of bug patterns, an extremely useful concept that will increase your ability to detect and remedy bugs in your code. You will learn about one of the most common bug patterns, which will lay the groundwork for you to begin recognizing and avoiding more advanced patterns.
|
|
Simple modeling tools
Simple tools, such as index cards, paper, and whiteboards, are more than sufficient for the majority of your modeling needs.
|
|
Service implementations for EJB and non-EJB environments
This article describes how a service implementation can be designed such that it can be deployed in both an EJB capable environment (such as a Session bean) and in a non-EJB environment (such as a plain JavaBean component). Choosing the right set of interfaces and classes and bringing them together in the right way allows an application to be developed regardless of whether an EJB environment is available
|
|
Service implementations for EJB and non-EJB environments
As more and more programmers are using Enterprise JavaBeans (EJB) in their projects, the need for tools that simplify EJB development is growing. This article explores Container Managed Persistence (CMP) Entity Enterprise JavaBeans, and introduces a free tool for their creation.
|
|
Diagnosing Java code: The Split Cleaner bug pattern
One of the features of the Java programming language is that storage is automatically managed, saving the programmer from the bug-prone task of freeing memory after it has been used. Nevertheless, many programs still have to manipulate resources, such as files and database connections, that must be explicitly freed after use. Like manual storage management, there are many pitfalls that a programmer might encounter when managing resources in this wa
|
|
The OO design process: Use-case planning
In my last column, I introduced the notion of a formal use-case presentation. Use cases will be covered in the next several installments of this column. They are a complex topic, and there is a lot of material to cover, so we'll take our time and look at the issues thoroughly. This month we focus on how to decide which use cases to pursue, and other things we need to keep in mind as we plan our use cases.
|
|
Java modeling: Holonic software development, Part 1
Granville Miller temporarily abandons the topic of requirements gathering for one more compelling: holonic software development. Find out how this method complements and extends the tenets of the agile development movement, and how its emergence into mainstream development circles may alter the education of software developers, as well as the practice of software development
|
|
OO design process: Use cases, an introduction
In previous articles, we've refined the problem statement and mocked-up our educational software. In this article we'll look at use-case analysis
|
|
Agile Modeling (AM)
Agile Modelers believe that you don't need to develop documentation the size of a telephone book to develop complex software.
|
|
When is a model agile? Part 1 of 2
Agile models fulfill their purpose, are understandable, and are sufficiently accurate.
|
|
When is a model agile? Part 2 of 2
In When is a model agile, Part 1 , you discovered that agile models fulfill their purpose, are understandable, and are sufficiently accurate. However, this isn't enough, they must also exhibit the additional traits outlined in this tip. They must be sufficiently consistent and sufficiently detailed, they must provide positive value, and they must be as simple as possible.
|
|
Object Initialization in Java
This article describes in detail the process of object initialization in Java programs. It discusses constructors, initializers, instance initialization () methods, initialization and inheritance, object images on the heap, and the order in which an object's variables get initialized. It serves as a companion article to this month's Design Techniques column, "Designing object initialization."
|
|
Designing Object Initialization
This installment of the Design Techniques column begins with a quick look at object-design fundamentals, then goes on to discuss various approaches to designing initializers and constructors so as to facilitate the proper initialization of objects.
|
|
Designing Fields and Methods
This installment of the Design Techniques column shows how some fundamental software design techniques, like avoiding special data values and minimizing method coupling, apply to Java
|
|
What's a Method to Do?
In this installment of the Design Techniques column, brush up on how -- and why -- to divide a class's functionality among its methods. I demonstrate how to maximize method cohesion while keeping the total number of methods to a manageable level
|
|
Object Finalization and Cleanup
This installment of the Design Techniques column discusses the design guidelines that pertain to the end of an object's life. I give an overview of the rules of garbage collection, discuss finalizers, and suggest ways to design objects such that finite resources aren't monopolized
|
|
The Hotspot Virtual Machine
This article, while not part of the Design Techniques column, discusses a topic that is closely related to the column's focus: performance. This article describes the "popular lore" that aims to improve the performance of Java programs in ways that reduce the flexibility of the code, and describes Sun's Hotspot JVM in technical detail. The article shows how Hotspot attempts to eliminate the performance bottlenecks that gave rise to the "popular lore" in the first place
|
|
Exceptions in Java
For those of you who need a refresher on exceptions, this cover story companion piece is a valuable tutorial on the nuts and bolts of what exceptions are and how they work in the Java language and virtual machine. I describe in detail exception mechanisms built into the Java programming language. I also discuss exception classes and objects, throwing and catching exceptions, the method invocation stack, the throws clause, checked vs. unchecked exceptions, and finally clauses
|
|
Designing for Thread Safety
This installment of the Design Techniques column gives you design guidelines that pertain to thread safety. It provides a background on the concept of thread safety and shows several examples of objects that are and are not thread-safe, including two illustrative applets. In addition, the article offers guidelines to help you decide when thread safety is appropriate and how best to achieve it
|
|
Event Generator Idiom
In this installment of the Design Techniques column, I propose the "event generator" as a Java idiom. The article provides a background on the concepts of patterns and idioms, describes the observer pattern, and demonstrates the idiomatic way to implement the observer pattern in Java
|
|
The Canonical Object Idiom
In this installment of the Design Techniques column, I propose "the canonical object" as a Java idiom. The article discusses the fundamental services that all objects in general should offer, shows how objects can offer these services, and names such objects "canonical."
|
|
Composition versus Inheritance
In this installment of my Design Techniques column, I analyze the flexibility and performance implications of inheritance and composition, and I give guidelines on the appropriate use of each.
|
|
Designing with Interfaces
In this installment of my Design Techniques column, I describe the process I went through to understand Java's interface. I talk about multiple inheritance and the diamond problem, polymorphism and dynamic binding, separation of interface and implementation as the spirit of Java, and my ultimate epiphany on how we should think about and use interfaces when we design.
|
|
Designing with Dynamic Extension
In this installment of Design Techniques, I take a look at a less commonly understood aspect of Java's architecture: dynamic extension. I discuss the two kinds of dynamic extension, forName() and class loaders, and offer guidelines on how to use these tools to make your programs more customizable.
|
|
Designing with Dynamic Extension
In this installment of Design Techniques, I give advice on using runtime class information in Java programs. I talk about the method area of the JVM and the structure of Java objects, upcasting and downcasting, polymorphism and dynamic binding, java.lang.Class and reflection, and -- perhaps most importantly -- I reveal how best to ask a hippopotamus to dance
|
|
Designing with Static Members
In this installment of his Design Techniques column, I discuss the ways in which static fields and methods, which exist outside of objects, fit into object-oriented design
|
|
Farewell to 'Design Techniques'
In this installment of his Design Techniques column, I discuss the ways in which static fields and methods, which exist outside of objects, fit into object-oriented design
|
|
Designing with exceptions
This article focuses primarily on how to decide when to use exceptions, and gives several examples from the Java API that illustrate appropriate uses of exceptions. In addition, the article provides some general guidelines that can help you use exceptions in those situations where you've decided they are appropriate.
|
|
New J2EETM Patterns Catalog Helps Solve the J2EE Architecture Puzzle
The J2EE Patterns describe typical problems encountered by enterprise application developers and provide solutions for these problems.
|
|
How to implement state-dependent behavior
Doing the State pattern in Java
An object in a program frequently has an internal "state," and the behavior of the object needs to change when its state changes. For example, the acceleration characteristics of a car depend on its current RPM range -- in other words, on its "state." The State pattern takes advantage of polymorphism to implement such state-dependent behavior in an object-oriented program.
|
|
Introduction to "Design Techniques"
This first installment of the new Design Techniques column introduces the column and discusses the larger issues involved in designing Java programs. In addition, we'll examine the software development process in general, describe the role of design within that process, and look at the various and competing goals of a "good" software design
|
|
Implementing Basic Design Patterns in Java
An interface encapsulates a coherent set of services and attributes (broadly, a Role), without explicitly binding this functionality to that of any particular object or code.
|
|
AWT Patterns
|
|
Design for Open Systems in Java
|
|
Java Tip 68: Learn how to implement the Command pattern in Java
Sometimes it's necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request. In procedural languages, this type of communication is accomplished via a callback: a function that is registered somewhere to be called at a later point. Commands are the object-oriented equivalent of callbacks and encapsulate the callback function. This Java Tip demonstrates how to implement the Command pattern in Java.
|
|
Clever Facade makes JDBC look easy
This month's tool saves you some work when dealing with common JDBC operations. You can use the Facade design pattern to encapsulate the most popular JDBC objects, thereby hiding all the tedium of initialization, exception handling, and cleanup.
|
|
Design networked applications in RMI using the Adapter design pattern
Creating a networked application is easy using Java's Remote Method Invocation. However, taking a non-networked class and jazzing it up for the network is definitely not the way to go. This will just lead to mess -- slow, hard to read, and difficult to maintain.
|
|
Best Practices for Object Design
By Bill Veners
|
|
Articles about Java Design
By Bill Veners
|
Appreciate the significance of the object
Objects are for people, not for computers. The point of objects is not to help computers run software, but to help people develop software. Computers are just as happy running assembly language programs as object-oriented programs. But people are happier writing object-oriented programs. OK, if not always happier, then hopefully at least more productive. The main aim of advances in software technology, from machine language to assembly to procedural languages to object-oriented languages, has been to help programmers do their jobs. In particular, objects help programmers manage complexity and change in their software.
By Bill Veners
|
See objects as bundles of behavior, not bundles of data
One of the most basic object-oriented ideas is encapsulation -- associating data with code that manipulates the data. The data, stored in instance variables, represents the object's state. The code, stored in instance methods, represents the object's behavior. Because of encapsulation, therefore, you can think of objects as either bundles of data, bundles of behavior, or both. To reap the greatest benefit from encapsulation, however, you should think of objects primarily as bundles of behavior, not bundles of data. You should think of objects less as carriers of information, embodied in the data, and more as providers of services, represented by the behavior.
By Bill Veners
|
Design Service-Oriented Objects that use their state to decide how to behave
When I was first struggling to understand object-oriented programming, I happened to leaf through a copy of Object-Oriented Design with Applications by Grady Booch. In this book I found a sentence that gave my my first real insight into what an object is.
By Bill Veners
|
Understand the relationship between mutable Service-Oriented Objects and state machines
In Guideline 1, I said that objects are machines. The kind of machine that service-oriented objects resemble, mathematically speaking at least, is the state machine
By Bill Veners
|
Use Messengers to transmit information
Guideline 2 encourages you to think of objects of bundles of services, not bundles of data. This guideline irreverently suggests that sometimes its OK to design objects that are bundles of data.
By Bill Veners
|
Use Messengers to transmit information
Guideline 2 encourages you to think of objects of bundles of services, not bundles of data. This guideline irreverently suggests that sometimes its OK to design objects that are bundles of data.
By Bill Veners
|
Use Flyweights as pluggable nuggets of behavior
This StampDispenser really offers the same service to clients as the StampDispenser in example 1, but through a different interface and with an implementation that is more code-heavy than example 1. Were I to have to implement a StampDispenser, I would do it the way I did in example 1. With example 2, I wanted to show how state machines and service-oriented objects are similar, and I wanted to have a launching point for using the state pattern.
By Bill Veners
|
Use Immutables to represent values of abstract data types
With a mutable object like the StampDispenser in Listing 3-1, identity is important. If I have 3 stamp dispenser machines and I enter a dime in one and a dime in another, I don't get a stamp. I have to insert at least 20 cents in a particular stamp dispenser to get the stamp. The identity of the machine into which I insert that second dime matters -- it has to be the same machine in which I inserted the first dime.
By Bill Veners
|
Use Immutables to represent values of abstract data types
With a mutable object like the StampDispenser in Listing 3-1, identity is important. If I have 3 stamp dispenser machines and I enter a dime in one and a dime in another, I don't get a stamp. I have to insert at least 20 cents in a particular stamp dispenser to get the stamp. The identity of the machine into which I insert that second dime matters -- it has to be the same machine in which I inserted the first dime.
By Bill Veners
|
MQSeries Programming Patterns
Today MQSeries offers the programmer more choices than ever in which to write new MQSeries applications, from the most traditional Message Queue Interface API all the way through to the popular and highly portable JMS interface.
Because of the many options available, it can sometimes be difficult for an application programmer new to MQSeries to easily understand the differences and benefits of each, or appreciate the implications of using one programming approach versus another.
By IBM RedBooks
|