{CodingBlocks}.NET

iTunes Spotify PlayerFM Overcast Podchaser Pocket Casts iHeartRadio YouTube feed LinkedIn Twitter Facebook Reddit

Navigation

Software Design Anti-patterns

By 8 Comments

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | TuneIn | RSS

We’ve discussed design patterns too much. Now it’s time for some discussion about anti-patterns as Joe has dark visions about robots, Allen has to take sensitivity training, and Michael picks Arial.

Reading these notes via your podcast player? You can find this episode’s full show notes at https://www.codingblocks.net/episode65.

If you’d like to put some faces to the sounds, check out the video of this episode:




Sponsors

Survey

In light of the Apple machine building momentum around iPhone excitement, we ask: iPhone 8 …

iPhone 8 ...
vote
×

 

News

Software Design Anti-patterns

Abstraction inversion

  • Not exposing implemented functionality required by callers of a function/method/constructor, so that the calling code awkwardly re-implements the same functionality in terms of those calls
  • A complicated way of saying that a simple concept builds on top of a complex concept, rather than vice versa.
  • Some examples:
    • Implement two functions: one that prints out text to the console, the other that prints out formatted test to the console.
      • Normally you’d write the function that just prints text out first, and then implement the formatted version to call the first.
      • In this case, you write the formatted version first, then implement the plain version to call the other except without formatters
    • Using a Vector in Java to implement a fixed size list instead of an array.
      • Vector uses an array internally
    • Markup languages as a data storage format
      • You serialize an object to XML. Then you read it in. You have some DOM. Now you program data representing the markup representing the program data.
  • Sources:

Ambiguous viewpoint

  • Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
  • Business viewpoint (Problem-Domain/Conceptual/Essential)
  • Specification viewpoint (System)
  • Implementation viewpoint (Software/Design)

Big ball of mud

  • A system with no recognizable structure
  • Software system that lacks any type of perceivable architecture
  • Due to code entropy – complexity grows as modifications are made
  • Spaghetti code – unregulated growth and repeated, expediant repair
  • Typically developed over a long period of time with multiple developers OR
  • Working on small parts of the problem incrementally over time rather than understanding the full problem at the outset
  • Why do they exist??? BECAUSE THEY WORK INITIALLY – but then become extremely difficult ot maintain over time

Database-as-IPC

  • A database is used as the message queue for routine interprocess communication in a situation where a lightweight IPC mechanism such as sockets would be more suitable.
  • Slow, inefficient
  • Popular because DBs are more widely understood

Gold plating

  • Continuing to work on a task or project well past the point at which extra effort is adding value
  • Uh, wait…who has this problem?
  • Maybe we can interpret this as YAGNI? Building a CRM when the customer wants a spreadsheet

Inner-platform effect

  • A system so customizable as to become a poor replica of the software development platform
  • When the software being created ends up being a replica of what it’s designed to work in due to designing it overly-customizable
  • Like when Filezilla was built on top of FireFox to create an FTP client, thus duplicating what the OS can already do
  • EAV tables in a relational database RDBMS – takes away the strength of the database and forces the application to do all the work
  • Overly generic schemas in XML or JSON making complicated code to extract value
  • When done properly it’s to have a “portable” inner system – Java, .NET Core, Docker?

Input kludge

  • Simple user input is not handled
  • You try to proper verify, santize user input and inevitably you missed something
  • Difficult to unit test, but users seem to find them with ease
  • Buffer overflow is a common example
  • Ways to detect:

Interface bloat

  • Making an interface so powerful that it is extremely difficult to implement
  • Sign of violation of Interface Segregation Principle
  • Widget example: Start off w/ a Render(), then a Save(), then a Restore(), then a Export()….
  • Example: implement IList in C#: IsReadOnly, Count, Add, Remove, IndexOf
  • If you find yourself adding methods that throw “NotImplemented” or // not needed…

Magic pushbutton

  • A form with no dynamic validation or input assistance, such as dropdowns
  • User Interface (UI) and Business Logic are forced through a magic pushbutton
    • Everything in the UI must be completed before the pushbutton is pressed AND business logic can only be enforced AFTER the button is pressed
  • Sometimes forces bundling of unrelated components simply because the pushbutton design allows for no proper separation of those components

Race hazard

  • The behavior of an electronic, software, or other system where the output is dependent on the sequence or timing of other uncontrollable events.
  • Often happen when processes or threads depend on some shared state.
  • Can be difficult to reproduce since the end result is nondeterministic and depends on the relative timing between threads
    • Production problems can disappear when running in debug mode, or additional logging is added
    • Known as the Heisenbug – a bug that seems to disappear or alter its behavior when one attempts to study it

Stovepipe system

  • A barely maintainable assemblage of ill-related components
  • AKA as silos. features work up and down…but not so side-to-side
  • Can lead to reinventing lots of wheels
  • Signs include copying/pasting, needing to “remember” or look at examples
  • Some benefits: avoid dependency hell, minimize unnecessary changes, able to make sweeping vertical changes

Resources We Like

Tip of the Week

Share the joy