Chicago C/C++ Users Group Message Board › Avoiding objects

Avoiding objects

Conrad W.
CWeisert
Chicago, IL
Post #: 45
After encountering several examples in the past week where writers chose to represent data items as unstructured string data rather than instances of a rather obvious O.O. class, I drafted this little article
http://www.idinews.co...­
It applies to C# and Java as well as C++.

This is a long-standing pet peeve, that seems to be growing.

I'd welcome comments from our group before I publicize it to the world around August 1.
Nevin ".
nliber
Libertyville, IL
Post #: 26
Given:

string customerName;
.
string city;
.
string productCode;

Yes, each of these should be a separate type, and that is independent of the representation underneath. A customerName is NOT a city which is NOT a productCode, and the type system should reflect that.

1. It makes it much easier to reason about the code.

2. The type system can prevent errors for occurring in the first place.

3. You can then add constraints, class invariants, etc.


So why don't people do it more often? Unfortunately, it is very tedious to do so.

For example (not tested), even keeping string as the underlying representation, a C++ class to encapsulate just one of these would look something like:

struct CustomerName : boost::equality_comparable<CustomerNa­me>
{
CustomerName() {}
explicit CustomerName(std::string const& name) : name(name) {}

friend bool operator==(CustomerName const& lhs, CustomerName const& rhs)
{ return lhs.name == rhs.name; }

friend bool operator<(CustomerName const& lhs, CustomerName const& rhs)
{ return lhs.name < rhs.name; }

friend bool operator<<(std::ostream& lhs, CustomerName const& rhs)
{ return lhs << rhs.name; }

friend bool operator>>(std::istream& lhs, CustomerName& rhs)
{ return lhs >> rhs.name; }

private:
std::string name;
};

This is *a lot* of work. There are some template techniques which can mitigate this, but still...
Nevin ".
nliber
Libertyville, IL
Post #: 27
As for what the representation should be within the object, I disagree with the article.

Strings may be perfectly appropriate for the problem domain at hand. A "city' could be represented as a string if it is just being used to print out mailing labels. If it is for, say, a GPS mapping allocation, then many of the fields you mentioned (name, location, population, founding date) are neither necessary nor sufficient to describe the data. And there may be efficiency concerns (both speed and/or size) of keeping all that data in the object itself.

"In a mature software development organization, individual programmers wouldn't even be making these choices." Oh, really? How can they possibly tell me what representation is appropriate for my task at hand? Now, there may be constraints that get imposed (say, if I have to interact with a corporate database), but I view those as additional requirements.

"Upon appropriate review and approval that standard would have been disseminated through a corporate data dictionary or other standards repository." Again, why? It's one thing if I have to interact (say, via a database or messaging) with software written by other parts of my organization (in which case we, of course, have to come to some agreement on how to do that), but again, that is just another requirement.

Good requirements tell what needs to be done. Bad requirements tell *how* it needs to be implemented. This is why systems engineering (gathering of requirements) is a different skill set than software engineering.

I've worked at places that wasted lots of money because the systems engineers were doing software engineering in their requirements, and we ended up going through many iterations (ie, cost our company money) because their assumptions on how the software should be implemented were just plain wrong.
Conrad W.
CWeisert
Chicago, IL
Post #: 46
Sorry, I didn't make my point clear enough. Nevin is right to observe:

"A "city' could be represented as a string if it is just being used to print out mailing labels.
If it is for, say, a GPS mapping allocation, then many of the fields you mentioned (name,
location, population, founding date) are neither necessary nor sufficient to describe the
data. And there may be efficiency concerns (both speed and/or size) of keeping all that
data in the object itself."


But we need to distinguish between two very different objects: a city and a cityName.
It's the former that contains the extra fields. It's the latter that I was proposing ought to be
used instead of a raw string in order to accommodate mailing labels and standard
representation.
Conrad W.
CWeisert
Chicago, IL
Post #: 47
I agree completely with Nevin's point:

"Good requirements tell what needs to be done. Bad requirements tell *how* it needs to be implemented.
This is why systems engineering (gathering of requirements) is a different skill set than software engineering."

Indeed that's the main point of my article
http://www.idinews.co...­
In fact, I'm about to start teaching a course at Loyola that about requirements.
http://webpages.cs.lu...­

A clear distinction between what and how is essential, But good
data-representation standards, whether at the worldwide, organization, or
individual project level, are still needed and have no relationship to user
requirements for a new application. They have a huge relationship, however,
to objects.

This could be an interesting topic for a User Group panel discussion.
I suspect that many of our members don't fully appreciate it.
Powered by mvnForum

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy