Business Objects are objects that
correspond directly to concepts in the actual business the software is meant to
represent and that encapsulate all decision making related to those concepts.
Often there is a
chasm between how a business person perceives a business and how a software
developer implements that business as software. Developers have to translate
what is being said by a business analyst into the technology that is managing
that business. Using object-oriented technology to create business objects
representing the same structures business analysts speak of goes a long way
towards improving the communication about and the design of an application.
Applications that
represent a business are all about making decisions and providing support for
users to make more decisions. We try to have the code make as many
of those decisions as it can. Examples include: Can a user login with this
password? Can this Truck carry this Shipment? What’s that fastest route from Point
A to Point B? The logic that determines the answers to these business questions
is referred to as business logic. Business logic can be tough to
figure out, easily done wrong, likely to change throughout the lifetime of the
application, and is arguably the most important code written in an application.
Duplicating this logic (on purpose or accident) is the source of much
frustration and many bugs. Business objects are created to encapsulate this
logic. The data used in these decisions are hidden away inside the object so no
other code tries to make the same decisions, and no other code is affected when
that data is changed to better support the logic.
There are many books
and articles about how to come up with the best objects for a business, so I
will not bother trying to sum up what volumes have been written about. In a
nutshell, objects are created for any business concept that plays a part in the
application’s requirements. All business logic is encapsulated in these
objects, with each object answering the questions they are logically and
usually best suited to answer. For example, if user interface code
wanted to know if a password entered is valid for a particular user then that
code would ask the User object: user.IsThisYourPassword(password)
Business objects often cannot follow every heuristic of object-oriented design because of the nature of the common business application. For example, a standard OO tenet is that an object should not expose any of its data. However, in the common business application, business objects are created on the fly by administrators who need to see all that data. Attempts to uphold this rule without compromise can result in complex designs.
See also: What is a business object?
No comments:
Post a Comment