Grundlig eftertanke

I väldesignad kod ser man ofta att mängden sammanhängande (jag använder en eufemism sedan ”procedurell” blivit ett skällsord) kod går mot noll, och mängden strukturelement mot oändligheten. Med ”strukturelement” menar jag språkets definitionselement — för typiska OO-språk skulle det vara klass- och metoddefinitioner.

Den här tendensen förstärks t.ex. av objektorienterade designmönster, som i sin iver att utnyttja polymorfism ökar antalet klasser för att kunna minska mängden villkorslogik.

Se på ett litet C++-program:

class Greeting
{
public:
  Greeting(const std::string& target)
    : m_target(target)
  {
  }

  void Utter(std::ostream& channel)
  {
    channel << "Hello " << m_target << "!";
  }

private:
  std::string m_target;
};

int main()
{
    Greeting greeting("Dolly");
    greeting.Utter(std::cout);
    return 0;
}

Vi har egentligen bara tre rader procedurell kod här, implementationen av Greeting::Utter och användandet av Greeting i main. Det betyder att 20 rader består av strukturelement. Av dem innehåller i sin tur tre (Greeting, Utter och main) namn som skänker någon sorts betydelse till programmet. Resterande 17 är mest syntaktiskt oväsen.

Fast jag hade inte tänkt smutskasta C++ & co här, läs Fowlers artikel för mer tankar om olika språks uttrycksfullhet.

Snarare vill jag kasta ut en fundering: skulle man kunna använda ration mellan strukturelement och kodelement som ett mått på designkvalitet? Något säger mig att det skulle funka ganska bra för språk som C++, Java och C#…