Software Design Approaches Discussion

Software design.

Why do we take the approaches that we do? Are object oriented domain models a good thing? Or are there more appopriate alternatives for most software?

These questions - and more - will be discussed (as they have been elsewhere ad nauseum, but hey, that's what makes technology great)!

[continued from OrTernaryRelationshipExample]

A significant factor in software design is developer background, including psychology, prejudices.

Very few people are almost equally confortable with functional programming, relational programming, logic programming and object oriented programming. Most people are not, although a recent text book on SoftwareEngineering from a GrandMasterProgrammer argues that the fluency in all the paradigms is a pre-requisite for the first course in Software Engineering. 

   My 'ideal' software engineering candidates have been taught one semester computer science 
   courses in at least (i) automata theory, formal languages and computability, (ii) algorithms
   and complexity theory, and (iii) the theories underlying algebraic, axiomatic and denotational 
   semantics. They have also been tought one or two semesters computer science cum programming
   methodology courses each in (i) functional, (ii) logic, (iii) imperative, and (iv) parallel
   programming, in (v) algorithms and data structures (basic, intermediate and advanced), in (vi)
   real-time, embedded and concurrent systems design, and a two-three semesters course in the kind of
   software engineering outlined in this essay. After all this come courses in (x) compiler design
   (xi) operating systems design (xii) database managemenet and database systems design,
   (xiii) distributed systems and protocol design, etc. All of these computer science courses are 
   based on the use of formal techniques: formal specification, analysis verification.


   From Dines Bjorner "Some Thoughts On Teaching Software Engineering" http://www.imm.dtu.dk/~db/documents/jacodebakker.ps
If it has been repeated to people that SQL is poo and objects are great, some people will find that objects are good and easy, even when objectively there's no reason to jump to that conclusion. Is the conclusion invalid then? For the developers in question I think their conclusion is most definitely valid. Given their background, their readings in object bigots, they may very well be less productive when working with SQL than when working with the more complicated O/R mapping approaches because of a psychological discomfort factor. If I were a team lead for such a team I'd carefully evaluate whether I had the time to root out some of their prejudices and let them think freely, or whether it's not more productive for the common cause to go the O/R mapping route.

Note that a good many RelationalWeenies do not think that SQL is the ideal RelationalLanguage.

In a lot of situations the O/R mapping route is the way to follow, and here I have little sympathy for the likes of TopMind who prefer to suggest that they can do better with their TableOrientedProgramming approach (don't mistake it, it's more FoxPro, and can barely be considered relational). The value of an individual working in a team is in the general case much greater than the value of him working alone. So an individual like TopMind would have to bite the bullet and eat objects for breakfast if that's how the team will be more productive. (Is this a LeftHandersTooCostly argument?)

On a much larger scale, though, I can't help but observe that teams themselves have to function in a larger context. For example I would hate if my team were less competitive than a team from India bidding for a project, because those guys will dump screens from VisualStudio, while mine would still UnitTest the DomainObjects and the O/R mapping. So there is some point in the larger context where "the good old way that the team knows" loses validity and the team may have to learn different ways.

I would like to suggest the book DomainDrivenDesign by Eric Evans ISBN 0-321-12521-5 . It has some excellent examples of domain models complete with behavior. -- JohnUrberg

I'm very sorry to disappoint you, but I've browsed that book when it was available in draft. As many other books on these topics it's a lot of talk, very little mathematics, and a lot of anti-relational prejudice, so I wouldn't waste my time on it again (for me ProgrammingIsMath). As far as I remember the domain examples were not to the level where a DelphiLanguage - like approach would not have been feasible or even significantly better by objective measures (lines of code, complexity, time to write) than the recommended "domain modeling" approach. I think it is difficult to avoid for most printed books on such a subject. -- CostinCozianu

I can't agree with broad prescriptive advice like "domain models should be avoided". I'm not sure it's always the best solution, and I do disagree with the anti-relational prejudice, but I understand the motivation.

The problem with a "Delphi"-like approach is that it doesn't give a lot of conceptual advice as to how to design software with lots of semantic constraints and triggers. One could do this with stored procedures and triggers, but there are quite a few thorny issues to deal with there. I'm familiar with one of the projects EricEvans talks about in his book (the cargo shipping management system). It's pretty complex, and I'm not really sure a RAD (i.e. VB/Delphi) approach would have sufficed. That system is still in production today, it's still unlike any other cargo shipping system out there, and that company is making a lot of money off of it.

At a fundamental level, Costin, you're quite right - ProgrammingIsMath. But the reality seems that most programmers have a hard time maintaining code that they didn't write. Most programmers a require a conceptual model on how they distribute behavioral responsibility. The world has had several paradigms here... functional, top-down, structured, and now object oriented. We need such conceptual models to understand how software can best be maintained. That's why a number of people find domain objects appealing.

Of course, and this is what I think I've learned from you, it can lead to the "Not Invented Here" syndrome - if it's not objects, I can't understand it, so it must suck. Or "when you have a hammer, everything looks like a nail". People start to ignore the computer science angle of programming and start creating a pseudo-science that All You Need is better object design patterns to write good, performing, simple, maintainable software.

Speaking of the psychological angle, it seems to me that there is a group that's obsessed with function and fitness (i.e. correctness and performance), which traditionally was the ANSI C camp, and lives today in the Linux/OSS world. And then there's another group that is obsessed with form (i.e. ObjectOrientedProgramming), because its focus is on the social aspects of software: growability, maintainability, habitability. This is what AlanKay seems to have aimed for: "The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be" (see AlanKayOnObjects for the full quote).

I think that great developers synthesize all three of form, fitness, and function - a combination of SoftwareHabitability?, DesignForPerformance, and DoTheSimplestThingThatCouldPossiblyWork.

-- StuCharlton

Re: the likes of TopMind who prefer to suggest that they can do better with their TableOrientedProgramming approach (don't mistake it, it's more FoxPro, and can barely be considered relational).

I would like more clarification on this viewpoint, but perhaps in another topic. -- top

Costin, those who have an aversion to relational are probably going to stay that way. I give up trying to sell the benefits of relational and tables to them. Their minds just do not map well to relational for whatever reason and we are not likely to change that. They like messy, inconsistent navigational structures for some bizzar reason. The best we can do is perhaps stop anti-relational propaganda as found in a lot of books and training material so that those who someday may "get it" are not scared away. However, I personally would still like to figure out the psychology behind navigational preferences, but probing always seems to end up as FlameWars. I think relational fans tend to think declaratively while OO fans think behaviorally. -- top

CategoryDiscussion

EditText of this page (last edited November 12, 2004) or FindPage with title or text search