Programming with
a dose of satire.
Design
|
| ||||||||
 |
 |
|||||||
|
Design |
|||||||||||||
|
Improve your interface design, by first thinking about the type of class that you are designing... Interface Design and Class Orientation By Robin Sharp This article is divided into the following pages: 1. Introduction
Introduction Object Oriented design patterns have brought great benefits to software engineering. However, there are other types of design pattern that can be used to good effect in your applications. When I hear discussions about Object Oriented design patterns being applied across an entire architecture, the O's in the OO acronym remind me of the eyes of animals who have frozen in a car's headlamps. The tendency to over-apply Object Oriented design patterns has led to the neglect of good lower level functional and higher level architectural design aspects of software. This article separates interfaces into four different types of orientation, and then discusses each type with regard to its relevance to good architectural design. The four interface types are: Function, Object, Service and Component.
It is important to make a conscious effort to distinguish between Function, Service, Object and Component oriented classes when designing software. A consequence of this is that it becomes a lot easier to build architecture neutral interfaces or reusable components. The code then becomes easier to use and test. Making a distinction between design patterns for types of classes and understanding where to apply them correctly can also have huge benefits on your code base and development times. Before beginning, a few qualifications are needed. Classes do not equate to Object-Orientation. However, they are almost always spoken about in the same breath; in fact, Object Oriented design patterns most often should form the majority of code in reasonable sized applications. When people talk of Architectural design patterns they are often talking about Object Oriented design patterns at the architectural level. There is nothing qualitatively different about them.
Classes of Orientation In this article, references will be made to the term HEAVY and LIGHT interfaces. We also refer to ACTIONS and ENTITIES (described below). The word LIGHT in this article refers to the narrowness of the types in methods and interfaces. LIGHT interfaces only expose the language neutral types (e.g. String, int, double, Date) where there are standardised mappings, such as the SQL92, JDBC and COM. HEAVY interfaces expose complex types with a large number of methods, and whose correct function may be dependent on call order. We also distinguish between ACTIONS and ENTITIES. ACTIONS refer to classes with no state, whilst ENTITIES refer to classes that hold state. Given these classifications, a distinction can be made between four types of class and the Orientation of their design patterns. The table below illustrates the four types of Orientation. Class Types and Orientation:
>> Next Page: Function Oriented Classes
Related Articles: Component Oriented Thinking: Separating Data From Architecture Automated Code Generation: The Fastest Way to Write Software?
Message Forum: Please let us know what you think of this article... Message Index:
The Messages: reviewthis is an excellent article. Could be even better if the example tackled a bigger problem set debjani debjaniroyc@hotmail.com Thu Oct 03 12:58:52 BST 2002 This is a great article. It may seem a little bit confusing and difficult at first sight, but the effort of reading it a few times until you fully understand is worth it! Try to apply these principles to your last project's code. Look where you made violations against these rules, and what impact they have on the maintainability and reusability of your code. This article really learnt me a lot, and I'm sure these insights will improve my future application designs. Gunther Van Roey gunther@javacoding.net Thu Jun 12 14:42:14 GMT 2003 The subtile of this article shows a big error in viewpoint. First of all I wanted to say that I have not read the entie article-I intend to do so immediately following this post. I do this so as not to predjudice myself against the article AND to show how big a red flag the subtitle "Improve your interface design, by first thinking about the type and orientation of the classes that you are designing" raised in my mind. I'm sure the article is excellent and I dont mean that to sound or be as backhanded as that might sound. My problem is this. The author immeidately posts the interface question question as something that can be answerd by some serious thinking about CLASSES. This misses the point. Interface design should always be done from the point of the USERS NOT THE CODE. Programmers who start of desinging an interface by thinking about classes, methods, and in some cases even programming languages are doing the interface design a great disservice. It is my believe that the interface should be designed FIRST, as it is usually the hardest thing to do in terms of "getting it right." Only after the UI is mocked up by a consensus between the users and designers should the programmers/architects decide on language/developement environment/classes, etc. One of the main reasons for this belief is the experience I have had (on many occasions,) of seeing application needs/requirments not spelled out until the UI design because THATS THE WAY THE CUSTOMERS ARE THINKING OF THE APP. Until they start to nail down the UI for you they really only have some vauge ideas in terms of requirments. Just my 2 cents, thought I owuld share, now off to read the rest. jd JD jdfelt@828royal.net NOLA, USA Tue Oct 07 02:21:07 BST 2003 re: The subtile of this article shows a big error in viewpoint. I bet you wish you'd read the article before posting now! As you've probably since noticed, the article isn't about user interface design at all. Dohh. "I know nothing so I will comment first to be pure of wisdom, before educating myself and thus commenting from some polluted standpoint." Riiight... Anonymous person Tue Oct 07 10:23:42 BST 2003
|
|||||||||||||
All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2007 Matt Stephens. ALL RIGHTS RESERVED.