{CodingBlocks}.NET

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

Navigation

Design Anti-Patterns: YoYo, The God Object and More

By 57 Comments

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | TuneIn | RSS

It’s time for more Ant-EYE or Ant-EEE design patterns as we venture into object cesspool that awaits. Come find out what these patterns are and how to avoid them. Bonus: Michael drops the term Heinz Doofenshmirtz – Joe and Allen didn’t know this pattern, but maybe you will.

Sponsors

Today’s survey …

How important is Docker?
vote
×

News

Get the Book Practical Test-Driven Development Using C# 7 on Amazon

Anti-Patterns

God Object

  • Concentrating too many functions in a single part of the design (class)
  • Typically knows everything about what’s happening in the application and knows how to interact with all the data in the application
  • Often gets incredibly difficult to maintain over time because making changes to the God object has far-reaching side-effects
  • Overly complicated because it knows about and maintains the state for much of the application – becomes a mediator of all things in the app
  • Pattern is used in micro-controllers where centralized control is more important than elegance and ease of maintainability

Object Cesspool

  • Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
  • This happens when you’re re-using objects (for example Pooling/Flyweight) and you either don’t fully clean up before/after
  • Example: I get a db connection from the pool, set the command timeout really high, use it, then return it…if my code doesn’t reset that…then every other call that uses that object may have that new timeout
  • Example: You install a blog engine like WordPress, create a new post and save it…then you go to write your second post and some of the information is not reset between uses…so you may end up setting a category, tag etc that you didn’t realize
  • Can also get into this problem if you’re working in a multi-thread environment and aren’t being thread-safe
  • How do you know when you’re doing this? Are you re-using objects or creating them on the fly? Do your objects have a “reset” method?
  • What to do about it? Try to centralize “reset” type code, use thread-safe tools/practices

Object Orgy

  • Failing to properly encapsulate objects permitting unrestricted access to their internals
  • Meaning, that other objects are able to “reach” into parts of your object that they really shouldn’t be able to
  • The worst consequence is that it becomes difficult to maintain and change.
  • An example of how this happens would be by declaring internal members public or providing public getter/setter methods on your properties.
  • This anti-pattern could be a symptom of coding to an immature design, laziness or haste while implementing the design, and/or reluctance to refactor the design as it matures.
  • How to fix this? Recognize the problem and refactor. This will be especially easier before any interfaces are made public.
  • favor private over public
  • OCP maybe?
  • The example we talked about with the RGB color space is directly to Joe’s own creation:
    http://colormine.org/

Please leave us a review!

https://www.codingblocks.net/review

Poltergeists

  • Objects whose sole purpose is to pass information to another object
  • Also known as: Gypsy , Proliferation of Classes , and Big Do It Controller Class
  • Typical cause is poor object design
  • Often found by names like manager, controller, startProcess, initialize…
  • They are short lived objects that have no apparent reason to exist other than to initialize a class or invoke a method in a more useful object
  • To remove one – get rid of it and move its functionality into the invoked class, through either inheritance or as a mixin
    A mixin can be viewed as an interface with implemented methods
    https://sourcemaking.com/antipatterns/poltergeists

Sequential Coupling

  • A class that requires its methods to be called in a particular order
  • Imagine an SDK like a credit card processor where you have to…Initialize your sdk, Create an Order, Add Items To the Order, Submit the Order for Authorization, Submit a Capture
  • How do you know when you’re doing this? If you catch you’re self saying “Oh, it’s because you didn’t…”, if you have an “Initialize” method, if you feel obligated to look for an example of how to do something
  • How do you fix it? Consider the template method pattern, create one method that does that stuff and have hooks like “initialize” and “before” / “after” events that implimenters can fill in – but not be responsible for calling

Yo-Yo Problem

  • A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation
  • Ever read some code, program, etc. that was so complicated you had to bounce between files, classes, etc. to understand it? That’s the yo-yo problem.
  • How can we avoid this?
    ** Maybe the S from SOLID to (help) keep your objects smaller?
    ** Favor composition over inheritance to keep the inheritance tree as shallow as possible.

Resources We Like

https://en.wikipedia.org/wiki/Anti-pattern

Tip of the Week

Share the joy