Reflections on software development . . .

Generally Speaking...

Joseph Reddy — Tue, 18 Nov 2008 08:24:12 -0600

I often find myself in conversations with developers on Experts Exchange, blogs or forums saying, “Generally speaking…blah, blah, blah.” Where blah, blah, blah is replaced by general rules of thumb in regards to development. This is an index of "Generally Speaking..." entries that will provide an easy link for me to point to and of course supplement my poor memory.

As always this is in regards to the common business application.

Generally speaking...

- The best software is never written

- Write something down
- Practice, practice, practice

- It is not about how fast you can get something done
- No spaghetti or balls of mud

- There are at least 3 layers to every application

- Favor theory over rules
- Programming a computer is easy
- Everyone writes hacks
- Business-Object-Oriented should be standard operating procedure
- Make the user more effective

Generally speaking...Make the user more effective

Joseph Reddy — Fri, 14 Nov 2008 16:37:28 -0600

I often find myself in conversations with developers on Experts Exchange, blogs or forums saying, “Generally speaking…blah, blah, blah.” Where blah, blah, blah is replaced by general rules of thumb in regards to development. This is one entry in a simple line of "Generally Speaking..." entries that will provide an easy link for me to point to and of course supplement my poor memory.

As always this is in regards to the common business application.

Generally speaking...

Applications (especially the user interface portion) should serve the user by making the user more effective, not more flexible. We have the tendency to try to create user interfaces that allow a user to do everything, have full control. At worst developers build an application as just a front end to a database essentially giving the user a database table editor. If that's all we were meant to do we would all be using Microsoft Access to create database front-ends.

Software should be a tool to help users do their job better. This requires that we work hard to understand their job. We need to gain understanding beyond the tasks they must complete and instead strive to understand their goals. This may sound a little touchy-feely but in the end it is really about learning the user's business and creating an application that makes the user more effective at their job. Replacing a file cabinet with a computerized file cabinet is not application development, it's called shifting the burden.

Generally speaking...Business-Object-Oriented should be standard operating procedure

Joseph Reddy — Thu, 13 Nov 2008 17:41:33 -0600

I often find myself in conversations with developers on Experts Exchange, blogs or forums saying, “Generally speaking…blah, blah, blah.” Where blah, blah, blah is replaced by general rules of thumb in regards to development. This is one entry in a simple line of "Generally Speaking..." entries that will provide an easy link for me to point to and of course supplement my poor memory.

As always this is in regards to the common business application.

Generally speaking...

Create an object model that models the business. Put business logic inside the objects, put process logic inside the services, and put implementation code in utility classes. Life as a business application developer gets immeasurably easier when you follow this simple, flexible, and technology-independent pattern.

Generally speaking...Everyone writes hacks

Joseph Reddy — Thu, 13 Nov 2008 08:19:03 -0600

I often find myself in conversations with developers on Experts Exchange, blogs or forums saying, “Generally speaking…blah, blah, blah.” Where blah, blah, blah is replaced by general rules of thumb in regards to development. This is one entry in a simple line of "Generally Speaking..." entries that will provide an easy link for me to point to and of course supplement my poor memory.

As always this is in regards to the common business application.

Generally speaking...

Everyone has to write a hack from time to time thanks to time constraints and other imposing factors. And by hack I mean code that we know is way less than perfect, smells bad but left alone, or a change in a model that is much different than maybe the database that supports the application. I often hack together methods on an object with full knowledge that my tests will bring out its dark side and help me refactor it later. What separates the masters from the merely competent is how hacks are written and what happens afterwards. When I stumble over my own hacks from a year ago I am reminded why I am not yet the master I wish to be.

Writing hacks should take place as deep as possible in the application. When we do write a hack we need to put the hack as deep in the code as possible so no code above it ever has to worry about the same issue again. Unfortunately some of the most hacked up applications have no choice but to implement hacks right in the user interface, the absolute last place where you want to do it.

It is too easy to just throw up our hands and decide we'll just have to hack something together so it works. When a hack is written it should be officially documented and the fix should be added to the top of the to-do list for the next release. Any and all implications to the model must be understood by all stakeholders.

No Broken Window Syndrome!

Generally speaking...Programming a computer is easy

Joseph Reddy — Wed, 12 Nov 2008 08:06:44 -0600

I often find myself in conversations with developers on Experts Exchange, blogs or forums saying, “Generally speaking…blah, blah, blah.” Where blah, blah, blah is replaced by general rules of thumb in regards to development. This is one entry in a simple line of "Generally Speaking..." entries that will provide an easy link for me to point to and of course supplement my poor memory.

As always this is in regards to the common business application.

Generally speaking...

Programming a computer is easy, productive and clear communication is very hard.

Work on the latter. <-- Universal Model

Work on the latter. <-- Object-Oriented Analysis and Design with Applications [Booch]

Work on the latter. <-- Communication Skills 101

Work on the latter. <-- Communication Skills 102 . . .

Work on the latter. <-- Start thinking out loud about what you think you know

Work on the latter. <-- Difficult Conversations: How to Discuss what Matters Most [Stone]

Generally speaking...Favor theory over rules

Joseph Reddy — Tue, 11 Nov 2008 08:10:35 -0600

I often find myself in conversations with developers on Experts Exchange, blogs or forums saying, “Generally speaking…blah, blah, blah.” Where blah, blah, blah is replaced by general rules of thumb in regards to development. This is one entry in a simple line of "Generally Speaking..." entries that will provide an easy link for me to point to and of course supplement my poor memory.

As always this is in regards to the common business application.

Generally speaking...

Favor theory, general methods, and the reasons why over rules, frameworks, and how things are done. It is not about how test-driven, or agile, or extreme, or object-oriented, or domain-driven, or feature-driven, or procedural, or [fill in the blank] design and development is done, it is why. Understand why and you can successfully apply the best practices in your own context.

For the life of me I cannot find the source of this. However, years ago a book was written by some CEO who turned a failing corporation around to make it very successful. Years after that the author discovered criticism for his book as the methods he described in his book were not proving successful for other CEOs. In speaking engagements the author would later address the naiveté of people who thought the same things would work for them. Readers failed to understand the why of what the CEO did. The bungling CEOs needed to comprehend the why and then come up with solutions for their own environment, their own context.

Generally speaking...There are at least 3 layers to every application

Joseph Reddy — Mon, 10 Nov 2008 08:10:09 -0600

I often find myself in conversations with developers on Experts Exchange, blogs or forums saying, “Generally speaking…blah, blah, blah.” Where blah, blah, blah is replaced by general rules of thumb in regards to development. This is one entry in a simple line of "Generally Speaking..." entries that will provide an easy link for me to point to and of course supplement my poor memory.

As always this is in regards to the common business application.

Generally speaking...

At a minimum, implement the most basic 3 layers of code (Presentation, Application, Data Access), even if they are not necessarily tiered. Anything else is muddy and has no place in professional development of the common business application.

Separation of concerns is the most basic axiom of good development.

Generally speaking...No spaghetti or balls of mud

Joseph Reddy — Thu, 06 Nov 2008 16:12:17 -0600

I often find myself in conversations with developers on Experts Exchange, blogs or forums saying, “Generally speaking…blah, blah, blah.” Where blah, blah, blah is replaced by general rules of thumb in regards to development. This is one entry in a simple line of "Generally Speaking..." entries that will provide an easy link for me to point to and of course supplement my poor memory.

As always this is in regards to the common business application.

Generally speaking...

No spaghetti, no balls of mud, no permanent hacking

Signs your application might be a plate of spaghetti, ball of mud, or permanent hack…

When you are faced with fixing a subsystem, object, function, or small chunk of code you often feel it would be easier to rewrite it.
When a business rule changes you are not sure where all you have to make the change. This can be a simple as “Let’s make sure all people’s names are displayed like this…” or as serious as “Let’s change all calculations done with dollar amounts to round like this…”
The objects from your “business” layer don’t have any "business" methods
Code routines have little separation of concerns and tend to be large
You routinely have objects with more than 10 properties
You have code that exists a year after you said it was just a temporary fix
You have no layers in your code, no discernable architecture.

Generally speaking...It is not about how fast you can get something done

Joseph Reddy — Thu, 06 Nov 2008 08:26:38 -0600

I often find myself in conversations with developers on Experts Exchange, blogs or forums saying, “Generally speaking…blah, blah, blah.” Where blah, blah, blah is replaced by general rules of thumb in regards to development. This is one entry in a simple line of "Generally Speaking..." entries that will provide an easy link for me to point to and of course supplement my poor memory.

As always this is in regards to the common business application.

Generally speaking...

It is not about the speed to completion, it is all about understanding and maintaining code which affects the overall speed of the application’s lifecycle. We deliver quickly by delivering little bits at a time with each little bit being well-built, well-tested, and easily changeable. Those bits being objects that like Legos can be used to build and change many different things in our application domain with great ease.

You should be able to check your code in at the end of the day without compilation problems. If you cannot then you are probably not delivering little bits of well-built, well-tested, and easily changeable code.

Know that your application will spend most of its life in maintenance and extension. The first build is only the beginning. Knowing this, build small with quality at every step. The first step to quality is a separation of concerns.

Do not engage in premature optimization or generalization. Worry about speed when it’s actually a problem. Make your code more flexible and generic when that flexibility is required.

Applications should evolve not spontaneously arrive. The metaphor of building an application being like engineering serves us well to a point. However, I cannot go to the mall where an escalator is installed and widen it by two inches to allow wheelchair access, but a change to the width attribute of an object can be done, tested, and released in an hour. In other words, the big design up front required for engineering physical things does not apply to the engineering of software.

Write as much test code as you can that does not require human interaction. This allows you to change and extend things fast and with confidence.

Generally speaking...Practice, practice, practice

Joseph Reddy — Wed, 05 Nov 2008 16:27:08 -0600

I often find myself in conversations with developers on Experts Exchange, blogs or forums saying, “Generally speaking…blah, blah, blah.” Where blah, blah, blah is replaced by general rules of thumb in regards to development. This is one entry in a simple line of "Generally Speaking..." entries that will provide an easy link for me to point to and of course supplement my poor memory.

As always this is in regards to the common business application.

Generally speaking...

The only thing worse than bad development practices, is no development practices. Developers can debate best practices ad infinitum, ad nauseam. However, even disagreement does not excuse having no practices at all. Although painful, it is worth seeing what a development team can agree on and sticking to as many best practices as possible. Doing this makes working on each others’ code much easier, let alone just understanding it. Furthermore best practices can help new developers avoid mistakes if they follow practices set up by the senior developers.

To avoid pointless disagreement, I have found it works best for a development team to figure out the least common denominator so to speak. The developers need to whittle down the debate to the point of intent and then ignore personal preference. For example, two development teams here quibbled over whether or not variable scope identification should be a prefix or a suffix on a variable. However, that debate was mostly a personal preference debate. What was most important is that both teams recognized the usefulness and elegance of scope identification and did something. They agreed they would not mix and match, but no one would declare a company-wide edict. Everyone is happy.

It is also worth staying mindful of what is personal preference and what truly has benefits and drawbacks. When you encounter something that makes your stomach churn but only because of personal preference, you can hold off speaking up and save your debate-points for something that really matters.

Generally speaking...Write something down

Joseph Reddy — Wed, 05 Nov 2008 08:03:39 -0600

I often find myself in conversations with developers on Experts Exchange, blogs or forums saying, “Generally speaking…blah, blah, blah.” Where blah, blah, blah is replaced by general rules of thumb in regards to development. This is one entry in a simple line of "Generally Speaking..." entries that will provide an easy link for me to point to and of course supplement my poor memory.

As always this is in regards to the common business application.

Generally speaking...

Regardless of how simple the new implementation or change you are about to make is…write something down. At my office, a particular developer is fond of saying, “Someone needs to think it through and write it down.” I couldn’t agree more.

On the smallest level you comment and pseudo code your way through the solution before writing code. Taken a step further you can scratch notes on the back of a napkin or have whiteboard discussions with other developers. But rarely is there a change so insignificant that you don’t at least write down in plain English what you think you are about to do. If you cannot say it in plain English, you cannot code it.

Generally speaking...The best software is never written

Joseph Reddy — Tue, 04 Nov 2008 12:27:11 -0600

The best code (easiest to maintain and has the least amount of bugs) is the code you never write. So you only build the simplest thing that provides value, careful never to add bells and whistles to an unstable code base.

An encapsulation misunderstanding

Joseph Reddy — Tue, 21 Oct 2008 13:36:16 -0500

In a discussion outside of this blog a developer suggested to me that encapsulation was kind of pointless in light of today’s more practiced methodologies. He said that we hide data behind a class so that if the data changed it would not affect anyone using the class. However, because he works on an agile development team with an iterative development cycle that lives and breathes changes, encapsulation was of little concern to him. His application is self-contained at his company so he is aware of all the client code. A simple change to a class’ interface and the compiler will point out all the places affected.

I explained that I too am in an environment where I have control over all clients of the object model so the affects of a simple data change can be easily handled. The encapsulation misunderstanding here is that exposing data is not the problem, or at least not the direct problem. Writing logic against exposed data is what leads to duplicated logic, difficult and incomplete tests, and a fragile design. I have mentioned previously in this blog that at the end of the day my business objects do expose their data, more than would be ideal for sure. The solutions required to prevent exposure are often just not that practical. What is of the utmost importance is that the correct reasons are understood for not abusing the exposed data so any abuse is less likely to happen. The less this is understood and enforced, the more dangerous exposing object data is.

If you are on a team of OO developers very keen to this understanding and code reviews or other practices are in place, then you could expose all your objects’ data without much fear of fragility. On the other hand, if you are surrounded by developers of varying OO-awareness then more ought to be done to hide object data so logic is not accidentally misplaced.

Is the Business Object Dead?

Joseph Reddy — Fri, 17 Oct 2008 08:14:31 -0500

By my estimations (and minor research), most common business applications being written today are in Java, VB.Net and C#. The languages are similar in many respects, not the least of which is that they are all object-oriented languages. I am aware that many if not most business applications written in these languages ignore 40+ years of object theory and proven layered architecture benefits on their way to a lovely big ball of mud.

However, there are legions of developers who do try to tap into the benefits of using an object-oriented design and a layered architecture to produce robust applications that are easy to build, understand, change, and maintain. When they do so they will make a decision as to whether an object representing a business concept will have methods for maintenance-related code or whether it will have methods that handle business logic. Rarely do objects have both as the two needs often lend themselves to different designs.

In the past year or so I have come to the surprising realization that most developers seem to make the methods of their objects maintenance related. The objects tend to be mutable bags of data that act only as a conduit to database tables for moving data in and out, business seems like an afterthought. Frameworks like nHibernate and CSLA promote this kind of design in much the way Microsoft does which is ironic since users of nHibernate and other O/R mapping tools tend to be anti-Microsoft developers.

Gone or least fading is the idea of objects that represent business entities actually having only methods that relate to the business of the object, in other words, they are true business objects. However, I’m not sure how an object-oriented developer whose emphasis is modeling a business in code rationalizes any other kind of design.

Obstacles to The Universal Model

Joseph Reddy — Wed, 24 Sep 2008 19:06:01 -0500

The classic design book from 1988 by Donald Norman, The Design of Everyday Things, is not about designing software, but rather designing any thing that must be used by a person. The author makes the point that a good design is easier to use, easier to learn, and simply better when the thing’s design reflects the user’s view of how the thing works, or in other words: the user’s model. The basic idea is that for any given thing there is the user’s conceptual model and the implementation model. The implementation model is exactly how a thing works or in other words, how it is implemented. Poor design either directly reflects implementation which is often no concern of the user, or the design reflects some model which is not the implementation or user’s model. A door that needs to be pushed designed with a bar that suggests you should pull it is an example that doesn't match either model.

Since software is just another designed thing, the 1995 book About Face was written specifically to address this issue in regards to building applications. Like the authors of many object-oriented books, these authors extol the virtues of building applications that reflect the users’ real-life view of the things involved. Doing this along with reflecting a singular language to describe the real-life views is what Domain-driven design methodologies and the book Domain-Driven Design refer to as creating a ubiquitous language.

When it comes to the common business application I firmly believe that an object-oriented solution based on one model that the stakeholders and developers agree on is the best way to build easily-understood and easily-maintained business applications. I like to refer to that common model as the Universal Model. The universal model is not the user’s model exactly or the implementation model, but rather a model that gestates over time based on the cooperation of stakeholders and developers. The success of that model depends on the cooperation and open-mindedness of both the developers and the stakeholders. Though I have found plenty of literature on how wonderful a combo of OO development, model-driven design, and a universal model is, there is little about just how hard it can be to come up with that model. Here are some of my notes on the obstacles to achieving a good Universal Model:

Obstacle 1: Geeks

Obstacle 2: Players don’t want to play

Obstacle 3: Compromise

Obstacle 4: Abstract Art

Obstacle 1: Geeks

Generally speaking, software developers are geeks who tend to see the world in 0s and 1s. By nature they tend to be interested in how things work and how to make things work. To them the implementation details are the real sexy details of an application (which might explain why many geeks do not care much for user interface development). Putting a universal model on top of their elegant implementation model can feel unnatural and even painful for a geek. The worst is an egotistical stubborn geek who believes that users just need to understand what is really going on because the universal model is the implementation model. The geek sees the implementation model as the only real model because it is true, clean, precise, logical, not-gray, 0s and 1, etc, etc,.

Geeks have to be made aware and then continually reminded who they are writing software for and who decides the success and relevance of their product. Geeks must understand that communication will play a huge part in the success of their development effort and we cannot be hindered by using two different dialects to describe the same system. Geeks can have trouble sticking to the universal model, even when they agree to the concept. Implementation details bleed into discussions, user interfaces, and other public access points [1] to the model. We have to all be vigilant to catch each other “leaking implementation."

Obstacle 2: Players don’t want to play

The software application is the universal model.

The universal model is produced by both the stakeholders and the developers.

Ergo the developers and stakeholders design the software application.

Ideally both parties will agree to this concept and work hard to achieve the universal model. However, often both geeks and stakeholders won’t play along. Stakeholders start tuning out non-playing geeks when they talk of arrays, tables, data source grids, and referential integrity. And then there are stakeholders who are used to the old way of developing software that entails writing up what you want and then getting an application 6 months or more later. Regardless of the poor software they have gotten in the past, these stakeholders are not interested in being active participants in the design of better software.

As with so many software development gotchas, an ounce of prevention is worth a pound of cure. From the beginning stakeholders have to be sold on the idea that they are designing the software by crafting the universal model. When they use terms that are not in the model, the developers should not assume anything and make the stakeholder clarify right there on the spot. Even when the stakeholders don’t play a long, it benefits us to try to figure out their conceptual model so when they speak in business-lingo we have less translation to do. When geeks won’t play along it behooves the team to move them deeper into the code and out of the public access points [1]. This allows them to work blissfully away on implementation code. When a geek that is not playing along speaks up in a meeting it might be worth restating what was said in terms of the universal model to make sure everyone is clear.

Obstacle 3: Compromise

Once upon a time I considered the user model the model that I had to match my design against. I would chastise myself and other developers who tried to introduce new terms into the universal model that did not seem to exist before. For example, when designing a system that managed when documents can be viewed I balked at a new concept called Viewability Specification. I argued that no one says that now or has before, and a user does not need to know about those kind of details. However, the concept did exist before; it had just never been labeled. Having a universal model requires that we label things and agree on how we will refer to these things. On the flip side, I had also been too strict about letting stakeholders use words that did not fit the reality of the design. For example, in a system that processes mass amounts of email, the users referred to the people who were sent emails as recipients. However, the geek in me pointed out that because of delivery problems not every person is truly a recipient of an email. So we used the term Addressee instead. Stupid. No one used that word, everyone continued to call them recipients, and the universal model was rendered pointless.

This compromise also means that stakeholders will have to understand some basic object modeling concepts. In a nutshell they need to understand that every thing in the system ties to an object and an object can figure things out based on what it knows. Some objects' state is stored so it can be used again even after a computer is turned off and back on.

We have to compromise on the model. There are times when developers will have to accept user-speak when it is more abstract than we would like, and users will have to refer to concepts with new terms not used before. Stakeholders and geeks alike can be anxious about the idea of stakeholders speaking in terms of objects, but the concept is so very simple and non technical. The truth is that this can only go so far. Stakeholders might be interested in some of the more gory design details but they will never want (or should have) to grasp the concepts of interfaces, classes, inheritance, or any other gobbledygook. So try as we might, 0% translation between real life and the model is not possible. Do your best, compromise where needed.

Obstacle 4: Abstract Art

Common disagreements in OO design often are in regard to levels of abstraction. What feels perfect for one developer is too abstract or too in depth for another. The universal model sits somewhere among the many levels of abstraction. The discussions about what is part of the universal model and what is deeper implementation is fraught with debatable material. Trying to discern whether a nuance needs to matter to a user can be tough. Most nuances are small, so on an individual basis they are easy to let slip into the model, however they do add up over time and can make the model too complex.

We have to ask ourselves what matters to the public consumer and producers of a concept in our model. Anything that does not matter does not need to be part of the universal model. For example, in the document system mentioned earlier we implemented 2 kinds of documents for various technical reasons. However, when consumed the user does not care what kind of document it is only that it contains information. When produced the administrative user could make changes that technically change it from being one kind of a document to the other, however, the kind did not matter to the user. To them it was just a Document with slightly different attributes. So the universal model only contained the Document even though the implementation behind the scenes had two specialized document objects. This problem can also be solved by putting extra notes in the model for anything that is debated. In the document example there was only a Document in the "index" of the universal model. However, in the fine print there were extra notes added for anyone who cared that explained the 2 specialized docs.

[1] Public Access Points of an Application

I use this term to refer to the user interfaces and all public objects and public interfaces of the system. This high-level code benefits from being the most abstract and an exact match of the universal model.

Benefits of the Universal Model

Joseph Reddy — Wed, 24 Sep 2008 19:04:20 -0500

Developing a universal model can be an easy way to get stakeholders to design the application without them having to learn anything technical. The basic object-oriented concepts of objects representing real-life things, determining things, and being stored is neither technical nor hard to grasp. Domain experts understand the complex interactions of objects in the real world; it is no stretch to visualize our software as a reflection of those same objects.

Realizing the effect of change is easy to see and communicate to stakeholders when they understand the model. They can see the ripple effect, or lack there of, when changes are suggested.

The universal model allows for the kind of gray, non black-and-white reality of a business domain to sit above the very black-and-white ultra-logical implementation details. When using an object-based language the majority of our code can directly match the universal model. Furthermore, it can also point out a gray reality that can even be implemented as gray instead of the assumed back and white.

Using service objects we can easily represent user-defined processes that still adhere to object-oriented principles of keeping all the logic in the business objects. These user defined processes can be part of the model and easily expressed in the same terms used in the business domain.

A step further

Joseph Reddy — Tue, 16 Sep 2008 08:39:44 -0500

Every good idea or programming practice can be taken a step further.

Every bad idea or programming practice can be taken a step further.

There is no end to the criticism of code because of this.

The Jerk Factor

Joseph Reddy — Mon, 08 Sep 2008 13:47:52 -0500

I have worked at 5 different companies in the past 13 years and have worked directly or indirectly with I’d say about 35 developers and other technical people. That’s not a huge number, but about an average of 7 IT people per job. The competence level, skill level, and social dexterity of those people all varied; however, I have only ever worked with 1 person who was what one might technically call an ass. Everyone knew it. Even those who were friendly with him knew he was a complete jerk. I would even suppose that he knows he is a jerk.

I bring it up now because it has taken me a while to realize what kind of impact a jerk has on a development team. Given a choice, no one wants to work with a jerk, let alone talk with a jerk if it was not absolutely necessary. Think about that for one moment and you can get an idea of what kind of simple havoc that can cause on development teams.

Regardless of how smart the Jerk might be, no one else is learning from the jerk.
Efforts can be made to create and follow "best practices" but no one will bother discussing them with the jerk
The group can work hard to make sure no one is a guy-in-a-room, but if no one wants to go in the room with the jerk then it seems inevitable a guy-in-a-room will emerge. Or maybe a jerk in a room?
This is a soft touchy-feely bit of reality, but the workplace is less relaxed. People tend to walk on egg shells around a jerk, put their head down as they pass a jerk in the hallway, and can be afraid to laugh or goof around near a jerk.
Developers as a whole are artists who are sensitive about their creations, having a jerk around only throws gas on a fire

The author of the book “The No *** **** Rule: Building a Civilized Workplace and Surviving One That Isn't” suggests that companies should try to screen for jerks and purge them from their ranks. I have not read the book, so I cannot tell you how he suggests we screen for them. However, from articles the author has written I can tell you his final advice is to try to avoid them, be polite but don’t engage, try to become indifferent and not care, and finally if all else fails, quit.

Spurred to write…

Joseph Reddy — Thu, 04 Sep 2008 10:14:10 -0500

Two quick things I feel like I have reminded myself or someone else of alot in the past few weeks...

It is worth remembering and being constantly reminded of, so it is worth writing down. Business objects serve a purpose. Granted, they abstract a concept in a domain, but we must think of them as being used to handle logic, to handle business, to have responsibility. I often document this in terms of what an object can determine, calculate, or figure out. Not doing this leads to a highly-coupled design. When we do remind ourselves to think along these lines we find ourselves exposing less data or finding other methods or abstractions to do so.

Windows forms and web pages are objects. General object-oriented rules should apply. They can and should have methods and properties. Their implementation details should rarely if ever be exposed to the public. Java, VB.Net and C# are OO languages. I said, Java, VB.Net and C# are OO languages.

Simple Object Patterns

Joseph Reddy — Sun, 20 Jul 2008 13:08:11 -0500

Simple Object Patterns

Referring to every object in an object-oriented business application as an "object" results in a vague lingo that does nothing to enhance design communication. Design is hard enough on its own, add a few more developers working on the same design and it benefits everyone to be able to clearly express differences in the objects involved.

The simple object patterns described here are not necessarily the complex patterns we usually think of when discussing object-oriented patterns. Rather they are single-object patterns or variations on a theme that are prevalent in the common business application. Many have to do with a separation of concerns of course, and many are useful in our effort to maintain an object-oriented design in a business application environment that seems to frequently conflict with OO principles.

Business Object
Business Object Collection
Set Object
Factory Object
Entity Object
Value Object
Key Object
Info Object
Detail Object
Service Object
Manager Object
Identity Object
Data Transfer Object
Data Wrapper
Candidate Object
User Interface Controller Object
Library Object
User Interface Choice Object

Simple Object Pattern: User Interface Choice Object

Joseph Reddy — Fri, 18 Jul 2008 13:33:29 -0500

User Interface Choice Object

Intent

Create an object to be used on a user interface that can represent a choice other than one of the single business objects made available.

Why

Consider a list box on a form that contains Ice Cream Topping Types. The user is required to choose a Topping but we don’t want to pick a default Topping for them. A common solution is to make the first option in the list box, “Choose Topping”. If the Topping was not required but we wanted to make sure the user clearly chose no Topping (didn’t forget to make a choice) the first option in the list box might be “No Topping.”

The list box in an object-oriented application would contain the Topping objects; however the top “Choose Topping” option is clearly not a Topping. A hack solution that corrupts the business layer is to add a bogus Topping object with a Name like “Choose Topping” and then let client code could figure out what to do with it.

A better solution is to create a UI Choice Object that contains the business object and tracks whether the option is No Choice, All Choices, or the Object. Instead of looping through the business objects and adding them to the list box, the code would first create a UIChoice object with a Display Property set to “Choose Topping” and set its Choice Type to “No Choice”. Then for each object in the collection it would create a new UI Choice and set its choice type to “Object” and adding that UI Choice to the list box.

User interface code can then check a chosen UI Choice object to clearly see if it is a No Choice object, All Choices object, or Business Object and act appropriately.

Implementation Notes

.Net developers can create a type-safe UI Choice object using generics to provide a standard way to put objects in and get objects out of list boxes and combo boxes.

Consequences

A reusable standard OO solution can be used across a GUI application without resorting to hacking

The business layer of a multi-tiered application is not corrupted by hacky solutions

Example Pseudo Code

class UIChoice<TypeOfObject>

{

private string _Display;

private UIChoiceTypeEnum _UIChoiceType;

private TypeOfObject _ObjectMaybe;

public string Display

{

return _Display;

}

public bool IsObjectChoice

{

return (_UIChoiceType == UIChoiceTypeEnum.ObjectChoice);

}

public bool IsNoChoice

{

return (_UIChoiceType == UIChoiceTypeEnum.NoChoice);

}

public bool IsAllChoices

{

return (_UIChoiceType == UIChoiceTypeEnum.AllChoices) ;

}

/// Returns the contained object this UIChoice refers to

public TypeOfObject Object

{

ThrowExpectionIfNull(_ObjectMaybe)

ThrowExpectionIfFalse(this.IsObjectChoice);

return ObjectMaybe_mObj;

}

Click here to view list of all Simple Object Patterns

Simple Object Pattern: Value Object

Joseph Reddy — Fri, 18 Jul 2008 12:32:18 -0500

Value Object

Intent

Create an object that is an attribute of another object without any identity relative to the domain and that can be interchangeable between objects that use the same attribute.

Why

I have a Person and a Person has an Address. I have a Company and a Company has an address. The database may have a PersonAddress table and a CompanyAddress table. However, there is no need to create a PersonAddress object and a Company Address object. A single Address value object can be shared by both the Person and the Company. All the logic related to an Address would be in that one place and can be tested without having a Person or a Company.

Implementation Notes

A value object is an object that often is used as an attribute of another object. For example, a Name object (value object) might be an attribute of a Person.

A value object has no changing state and has no domain identity, it is not an Entity Object. In other words, their lifecycle is not tracked in permanent storage. For example, an address does not change, a person might change addresses, but the address remains the same. In other words, the person gets a new address.

A car might have the attribute color. Color is a value object. The system does not track colors. The car’s color may change from Red to Blue, but Red never changes into a different color, it will always be Red

Whether or not an object is a value object can depend on the domain.

Consequences

Identifying that an object is not an Entity Object can simplify a design by making objects that are easily testable and not tied to what is ultimately a database that assigns identity.

Understanding them can help us see objects where at first we just saw primitive data types: e.g. Person with Zip code value object instead of type string

Click here to view list of all Simple Object Patterns

Simple Object Pattern: Library Object

Joseph Reddy — Fri, 18 Jul 2008 12:26:21 -0500

Library Object

Intent

Create a class that provides a list of functions related to a specific area of interest.

Why

Over time we eventually write various functions related to specific area of interest like Encryption, String Manipulation, etc. Often these functions are not domain specific and could be used in other applications that share the same interests. When we want to group these functions together we create a Library.

Implementation

These classes are often written with reusability in mind outside of the domain (Maybe not for the whole world to reuse but a development team or teams.) Sometimes they are specific to the business domain and shared by many objects.

Developers can get lazy and start putting functions in libraries that belong in business objects. It might be legitimate though to have a business object method turn around and call a more general method in a Library.

An effort should be made to make the libraries as independent as possible.

Examples:

ExceptionLibrary could have common exception handling routines like throwing errors when something is null, or building a readable message for an exception. This is the kind of stuff that any application could use.

StringLibrary could have routines for getting random characters, reversing a string, or any more complex manipulations that the basic string type does not provide.

Click here to view list of all Simple Object Patterns

Simple Object Pattern: User Interface Controller Object

Joseph Reddy — Fri, 18 Jul 2008 12:23:56 -0500

User Interface Controller

Intent

Create an object that can reduce the number of calls made by a remote user interface client and convert required data into format acceptable by client.

Why

Consider a web interface that lives on a web server but needs to work with an application that lives on a separate application server. Communication between the two is not quite lightening fast, yet we want the user to have a quick and responsive user interface. For example, when a user logins in we might want to check their security rights, get their current account information, get notification of any friends they might have on-line, and check to see if they have any answers to outstanding questions they may have asked. On a desktop application we would not think twice about the user interface making those four or more calls to get the information. We also would have no problem with the GUI retrieving the objects with that information. However, in the case of the web it can really benefit performance if the web client could make one call to a Web User Interface Controller across the network that will do all of that at once and return the results. Instead of serializing all the objects involved, we could just gain access to the one controller.

Implementation Notes

A Data Transfer Object is a useful mechanism for transferring the data from a single controller call.

Should be noted that a UI controller is specific to a user interface, if it wasn’t it would just be a normal application service.

Consequences

Network activity is reduced and user interface speed is increased.

Objects in the business layer are not corrupted in order to deal with a disconnected user interface.

Click here to view list of all Simple Object Patterns

Simple Object Pattern: Set Object

Joseph Reddy — Fri, 18 Jul 2008 12:19:43 -0500

Set Object

Intent

Create a collection that requires that all the objects it contains abide by one ore more requirements.

Why

When we want to write a method against the items in a Collection but find ourselves assuming that the objects all have a common denominator, it may be safer and just plain clearer to create a special collection called a Set.

Consider a business application with a Car object that contains a Tires collection. This design is fragile because of all the assumptions being made about the collection. For example, code could ask the Tires collection for the two front tires and it might bomb when it finds three front tires in the collection. An appropriate solution is to create a Tire Set which is a collection of Tires with strict rules about its members. This Set would enforce that it can only be built with four tires, two front and two rear, and they have to all be the same size. Now methods that are specific to a Tire Set, like GetTheTwoFrontTires() require no assumptions and will always work. Any methods of the plain Tires collection that make sense for the Tire Set can be made available through the Tire Set interface. A Car object would be built with a Tire Set, not a general Tire collection.

Implementation Notes

Often items in a domain only require one set. However, when we have multiple sets of objects in a domain, it is common to append what the set it for; e.g. TireSetForTruck - makes it clear that "These are Tires for a Truck", TireSetForDisplay, etc.

There may be no way that a collection can enforce the rules about its members. However, when a Set is built in the business layer, the rules can be enforced and public code can safely assume those rules have been followed.

Consequences

A more robust and obvious design.

Click here to view list of all Simple Object Patterns

Simple Object Pattern: Manager Object

Joseph Reddy — Fri, 18 Jul 2008 12:07:46 -0500

Manager Object

Intent

Create a Service Object that manages a process providing a clear interface to the steps available and necessary to complete the process.

Why

When a step by step process must be followed to complete a business procedure, it benefits client coders if the interface to the process is provided in the form of an object that acts like a tour guide through the process.

Implementation Notes

Manager Objects are just application services that manage a step by step process as opposed to a process that is just kicked off and then completes.

A common mistake when writing manager code is turning the manager into a “god class” or “agent.” God classes are the result of procedural coding with anemic objects. God classes pull data from other objects to make decisions as opposed to letting objects make their own determinations based on their data. It is everything object-oriented design is not. Good managers are like good managers in real life. Good managers trust us to do the right thing, but clearly direct us. Bad managers don’t trust us, meddle in our business, and end up making all the decisions.

An Agent class is similar and it tends to arise from developers not personifying objects (making them smart and able to do things). An agent class manages work between two or more objects as opposed to giving the work to one of the objects. Some feel that creating business services that work with objects leads developers to create agent and god classes that do all the work. I read once that no one sets out to create a god class, but when certain designs are combined with rushed schedules and multiple developers the god classes will emerge over time anyway.

Finally, another misstep that I have fallen prey to before is over-engineering the manager. It is good to make things easy for our client code, but if we assume that our client code is completely ignorant of the process then we can end up jumping through way too many hoops to manage things that the client could. The manager then becomes a source of bugs and frustration brought on by questionable complexity. I have found that it is plenty helpful enough if a manager labels the steps of a process based on their order, allows for the creation of a final result object after the last method is called, and or holds on to basic state changes while it is being used.

A quick example of a Manager Service managing state would be a QuizManager that is constructed with a Quiz and a Timestamp. The QuizManager would have methods for stepping through the Questions which would require it track the current question the client is on.

Click here to view list of all Simple Object Patterns