AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Delphi-PRAXiS - Lounge Delphi-News aus aller Welt Questioning Your Software Design Assumptions

Questioning Your Software Design Assumptions

Ein Thema von DP News-Robot · begonnen am 5. Feb 2020
Antwort Antwort
Benutzerbild von DP News-Robot
DP News-Robot

Registriert seit: 4. Jun 2010
11.416 Beiträge
 
#1

Questioning Your Software Design Assumptions

  Alt 5. Feb 2020, 11:30
While it is likely this post can stir some controversy, among my friends who are more "purist of design rules", I think a dicussion is well worth.*

I was searching totally unrelated information, when I hit the web site of my long time friend Bruce Eckel (of Thinking in Java and Thinking in C++ fame) and read this very interesting blog post:

Unspoken Assumptions Underlying OO Design Maxims

In the post Bruce refers to and comment this blog post by Julia @coding:

Flexible code considered harmful

Both are quite interesting, even if I don't agree in full I think they have a point. It is true developer very often over-architect their code in light of future extensions, resuming they know how the requirements will change and how they'll be able to extend the software because of their nice architecture. But how often this is true compared the times the software is never extended into that direction -- but in a different one -- and the over-architecture becomes immediately a cumbersome technical debt making negatively affecting other changes required (but unexpected)?

From Julia's blog, I find this provocative but honestly quite relevant:

"Keep in mind that speed is achieved by writing simple and direct code with as few abstractions as possible."

This is a thing I countered to the "RAD = bad design" crowd out there. I think this particularly applies to some over-designed JavaScript libraries out there, even though I'm far from an expert in the JavaScript world. Not don't take me wrong, it totally depends on the task at hand, the size of the application, and the requirements you are starting from. Honestly, it is another way of stating the KISS principle: Keep It Simple, Stupid!

Now, considering Bruce blog post he underlines some unspoken assumptions we have as developers (and software architects):

  • "We somehow know how a system will change"
  • "Abstractions are always worth their cost"
We need to question these assumption, and consider if they apply to the task at hand. It is not they are always false, but also they are not always true.

What I found particularly interesting is his comment about "programming against interfaces" and how this rule got morphed from "interface" as a concept to "interface" as a keyword. He refers to Java, but I've seen that applied to Delphi quite often. Now it is undeniable that an interface (in the language) offers much looser coupling than a class "interface" (the collection of public methods and properties) or a unit "interface" (type and symbols exposed by a unit and declared in the interface section), but all three scenarios account for "programming against an interface" in the original terms of the concept.

Am I saying you should not use interfaces? Absolutely not, it is a great language feature and helps reduce coupling and creating better and more flexible systems. What I'm saying is that the interface keyword*should not be the only abstraction you code against in a Delphi application.

I*really like the final recommendation by Bruce Eckel, which I'll rephrase as:*If you can only justify an abstraction*by #34ing a maxim, take it out!*

Happy coding ;-)



Weiterlesen...
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:13 Uhr.
Powered by vBulletin® Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf