The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Do my object-oriented leanings make me a fuddy-duddy?

After a couple years of solo programming, I have begun to work with a couple of other developers. I am surprised to find that neither seems to share my practices regarding code design or implementation.

I switched to object-oriented design in the '90s because I really believed it was a better solution than procedural programming. I believe in Abstract Data Types. I think Eiffel is the coolest thing around. I understand that the Fragile Base Class problem is a weakness, but by and large polymorphism is really productive.

The other developers seem to be not so interested in this philosophy. They glue existing stuff together. For instance, if you want some data on an ASP.NET web page, they'll code up a DataGrid that accesses a DataSet, and voila. I might design classes that represent the data, and spend a little more time on the data-access layer, in the hopes that I can reuse these structures in other places.

I'm trying to give an unbiased account, but I think you can infer that I still think my approach is "better." But I ask honestly: Did I miss the memo a couple years ago? Is the whole object-oriented design thing not as fruitful as people hoped it would be? Has the role of "software engineer for a web-based business application" been reduced to binding DataSets to WebControls?

Again, I ask in all seriousness. If I need to rethink my software strategies, I'd rather know sooner than later! If anyone can point me to articles that address this issue, that'd be delightful. And I welcome all discussion.

Just Dave
Tuesday, August 23, 2005
Some people like to design software, some people like to hack things together and get it out the door.  I, personally, would rather have a well-designed system, but not everyone is like me.
Tuesday, August 23, 2005
The people paying for it generally don't care.  If the other developer's solutions are cheaper and work well enough then *most* will not care how it was designed or developed.

Assembling pre-existing components to build a functional solution may be the best approach for the projects you're working on.  If so, you may need to look elsewhere if you want more challenging and fulfilling work.

There's nothing wrong with your perspective as long as you recognize that sometimes a pure object-oriented, reusable, polymorphic solution isn't the optimal one given cost/time constraints and team skill sets.  Don't waiver in your desire to build the best solution, just recognize that the best solution doesn't always mean the most elegant.

I personally prefer working with those who lean towards the purist side, since they tend to put more thought into their solutions. Just my experience.  Your mileage may vary.
Tuesday, August 23, 2005
You will find right places and wrong places to do OOP. You probably belong to the "custom-entities all the way in the business layer and have data access layers to support the freezing and unfreezing of such objects" school of thought.

With this school of thought: The advantage is that you get all the OOP benefits, and your business objects are typed, has all the behaviors and assertions they ought to have, and last bonus--they are light: the disadvantage is you also lose all the benefits of typed or untyped datasets. These simple collections and objects you use belong to you and you must maintain them. This takes time and if you enjoy babysitting your code and working with code generators (CodeSmith) and reinventing what Microsoft already has done with ADO disconnected data access, it could be your bowl of soup.

Your coworkers prefer the latter school of thought. 80% of the projects are throw-away, and when they drop back in, they want to see duct tape and agile development. With a simple UML diagram stuck to it using a bubble-gum--if you must. They aren't looking for a thick folder containing the blue-plan. So they use heavy objects like disconnected  datasets and datagrids, and call that a day. >>Sometimes even stuffing all three tiers into a button handler.<< If your coworkers decides to take this further and implement that huge 5 million dollar ERP system (the other 20% of projects) the same garage-band style--it won't be very managable. But for most tasks they aren't really wrong. And there's an entire department at Microsoft that says, chill man, you don't have to play architectual astronaut anymore. Use the Enterprise Library.
Li-fan Chen Send private email
Tuesday, August 23, 2005
P.S. Dave, you may already know the specifics between the two general methods of attack--if so--awesome. Otherwise here's a few read-ups:

Camp A: Use Custom Entity!

Camp B: No, use Typed or untyped DataSets!

Effective C# - 50 Specific ways to improve Your C#: Rule #41.


If you are looking for a happy ending for both you and your coworker, Enterprise Library (EL) (from the Patterns and Practices Group at Microsoft) may make the grade. Making use of EL gets you quite a bit of maturity in terms of site infrastructure. Everyone on your team gets a first-hand taste what benefits exist if one thinks ahead, without having you spend 6 month writing an untested proof  of concept (difficult to justify at times). Even if you don't want to use EL, your team may just walk away firmly in the camp of "let's do some of thes we do better".
Li-fan Chen Send private email
Tuesday, August 23, 2005
OOP vs structured is not an issue. Both approaches have their strengthes and weaknesses.

What makes a difference though is approaching development from an engineering perspective.
Dino Send private email
Tuesday, August 23, 2005
Maybe they had their desire for quality beaten out of them at a previous job (or the current one).  I know that's where I'm heading.  Measure never, cut twice, that's us.
Kyralessa Send private email
Tuesday, August 23, 2005
Um, did .NET stop being object oriented in version 2.0?

The .NET platform has some nice architecture.  You intend to write a bunch of stuff from scratch in the hopes that it might be reusable, while your co-workers are using objects that have already been proven to be reusable in a wide variety of real-world situations.  Who's making the better use of OOP paradigms? Are you sure you're not suffering from NIH syndrome?

On the other hand, I do feel your pain.  .NET does do some stuff in wierd ways.  One way to strike a middle-ground is to build custom controls that implement your logic while inheriting from the standard controls, adding your own logic on top.
Tuesday, August 23, 2005
Maybe they're Asian:

'“An American mother will say: ‘Look Billy, a truck. It’s shiny and has wheels.’ The focus is on the object,” explains Nisbett. By contrast, Japanese mothers stress context...'
slava Send private email
Tuesday, August 23, 2005
If you are doing development, then forget your Eiffel experience. I don't care how elegant you think your solutions  and architectures may be, if you are in the .NET world then you do things the microsoft way. Period. Steer your dev team towards here (the benefits of OOP you champion are well documented):

just my $.02...
...But What Do I Know
Tuesday, August 23, 2005
It sounds like you want to be a programmer and the other people just want to assemble digital furniture for a living.
son of parnas
Wednesday, August 24, 2005
A lot depends on the scale of the project. On small projects, OO doesn't add much value, but on large projects OO is quite helpful.

In my experience, the strongest benefit of OO is encapsulation. When each class exposes a well-defined public interface while hiding implementation details, it's easier to construct a large program. When writing smaller programs, a straightforward procedural approach works fine.
Wednesday, August 24, 2005
" For instance, if you want some data on an ASP.NET web page, they'll code up a DataGrid that accesses a DataSet, and voila."

I think that's the whole point of using datasets. If you had to design a similar system in PHP, Perl or possibly Asp.Classic you need to encapsulate everything in classes otherwise the project will become unmaintainable in the long term. Well, most of the time anyway.

You admitted your way of doing it is slower, and it has no tangible benefits. Unless you're -really- going to reuse the component, but in practice it rarely happens. My rule of thumb is that I write a good encapsulation if I know for sure I'll need the same object in several different contexts. This way you end up writing code at most twice, which is acceptable. Writing a good abstraction is a lot of work, and a leaky abstraction is in my opinion worse than no abstraction at all.

As soon as you encapsulate your object you start thinking about features you might possibly need in the future. Hardly relevant right here, right now.

Besides, code in which everything is an object isn't always easier to read or maintain.

(I'm just talking about objects to manipulate common controls and the likes. I'm not talking about the business logic, which usually does warrant a well thought out design.)

Wednesday, August 24, 2005
When you are working with an already well defined API, for  developing a simple website, experience shows there is no value addition in designing it with OOD. But on the other hand if you are developing a website like ebay (extreme case) or yahoo mail, where additional functionalities are the need of every hour, and downtime plays havoc with your profits, then my friend, patch up jobs with data sets are going to lose you, your job.
peddu Send private email
Wednesday, August 24, 2005
There's a strong movement to SOA and web services. Entities are going to serve you well in that world, not datasets. So if you think you might want to turn your work into a cross-platform web service, go the pure OOP enitites, customed-typed collections way, and not datasets.
Stacy Murray Send private email
Wednesday, August 24, 2005
I'd say that, given the information you have provided, it is impossible to tell which approach is best.

Having too much architecture can be as bad as having too little. What "architects" should be about is deciding how much architecture is required for each project not how to produce the technically most elegant or advanced architecture.

Thursday, August 25, 2005
Dave! No need to rethink your strategy. Go for an OO Architect or OO Software Analyst position. You will find it much more satisfying. Plus a better payment.

Denis Krukovsky
Denis Krukovsky
Thursday, August 25, 2005
what dave didn't mention (but did to me in an email on the topic) is that the other programmers are consulants. His story reminds me of a consultant we had who was exactly the opposite. He insisted on using this sort of textbooky class hierarchy, as if every problem can be reduced to class Square inherints from class Rectangle inherits from class Shape. Unfortunately it didn't really solve the problem; in particular it was an inflexible design. the guy got all defensive when we pointed this out to him.

In general, whatever programming thingy you use is fine if it solves the problem and does it in a maintainable and readable way. One thing about consultants is that they know they don't ever have to support their own code; they just swoop in, drop it like a turd, and swoop out.
Anne D Send private email
Thursday, September 01, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz