DEV Community

CodingBlocks

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

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 …

Anonymous Vote
Sign in with Wordpress
How important is Docker?
  • Very, Docker is the new Git
  • Eh, Containers are awesome, but Docker itself…
  • Nah, this is just a stepping stone to something much bigger
  • Just testing
  • Nope, I build and deploy from a laptop
  • Anytime, I can hear Michael's voice, would be awesome!!!
  • Once a week, around an hour time frame.
  • Keep the current release cycle, address simple questions with a 5-10 minute segment per episode, dedicate longer episodes as to questions as needed.
  • A 1 hour show once per week would be nice. Any shorter and things often start to feel rushed or superficial.
  • every 2 weeks, 45-1 hour. perfect.
  • 1 a week 1 hour long, sweet jesus
  • ~50 minutes once a week would be nice. .NET Rocks are around that length and I love them.
  • I think the best podcast length is likely equivalent to the mean commute time (~25-30 minutes). Twice a week would be great because it is easier to carry a thread. Also, I think the audience begins to forget your exist if they are released only every few weeks.
  • How about 30 minute weeklies and 90 minutes monthlies
  • I don't have time for 10 minute shows. 30 minutes is my cutoff. If a podcast is less than 30 minutes long I usually don't bother playing it because it's distracting to navigate to a different podcast. Considering I often listen in my car, at the gym, or while doing other things with my hands I don't like short podcasts. And besides podcasts are not television, who wants to be reminded of the crappy experience television provides making you reach for the remote every 10 minutes because of commercials.
  • Once a week but 30 mins is not enough to get into a topic. Officially I vote 1/week but if you have to go to every 2 or 3 weeks to have enough time to fully cover a topic I'd prefer that. Thanks guys, regardless of when you do it!!!!
  • 1 hour once per 5-10 days
  • If possible I would like to hear 2 shows a week around 30 minutes in length
  • bool isListenersHappy = (minutesPerShow == 60 && nrOfTimesPerWeek >= 1);
  • All of the above.. I want more!!!. You guys rock!
  • Twice a week. Each podcast is about 1 hour long.
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

Episode source