Sun, 15 April 2018
- 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
- 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
- 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:
Please leave us a review!
- 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
- 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
- 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
Tip of the Week
Direct download: codingblocks-episode-079-64.mp3
-- posted at: 8:00pm EDT
Mon, 2 April 2018
It's time for more cowbell as we have a special guest in the studio, Will Madison (@IAmWillMadison), join us as Allen finally gets tripped up trying to pronounce a name, Joe teaches us the value of practice, and Michael evacuates in a rainbow colored straight line.
Direct download: coding-blocks-episode-78.mp3
-- posted at: 10:49pm EDT
Sun, 18 March 2018
We're back with our last deep dive into Robert C. Martin's latest book, Clean Architecture, while Allen suffers from sleep deprivation, Joe shows us his dance moves, and Michael's mind is blown on how to unit test.
Direct download: coding-blocks-episode-77.mp3
-- posted at: 10:15pm EDT
Tue, 6 March 2018
It's time for another deep dive into Robert C. Martin's Clean Architecture as Joe puts us on the spot, Allen has a new mission, and Michael shares his Easter eggs.
Direct download: coding-blocks-episode-76.mp3
-- posted at: 10:32pm EDT
Sun, 18 February 2018
Michael can't tell higher from lower, Allen puts his views where he wants them, and Joe snaps it to a Slim Jim as we discuss how to make our architectures scream while discussing Robert C. Martin's Clean Architecture.
Direct download: coding-blocks-episode-75.mp3
-- posted at: 7:08pm EDT
Sun, 4 February 2018
It's time for another deep dive into Robert C. Martin's Clean Architecture as Allen warns us about driving in front of him, Joe tries to describe a diagram again, and Michael can't understand the survey results.
Direct download: coding-blocks-episode-74.mp3
-- posted at: 7:56pm EDT
Mon, 22 January 2018
Joe drinks too much coffee, Allen spits his coffee out, and Michael feels vindicated as the discussions about Robert C. Martin's latest book, Clean Architecture, continues.
Direct download: coding-blocks-episode-73.mp3
-- posted at: 9:59pm EDT
Sun, 7 January 2018
Joe baits Michael, Michael takes the bait, and Allen lets it happen, as Uncle Bob explains how we can quantify the coupling between our components from his latest book, Clean Architecture.
Direct download: coding-blocks-episode-72.mp3
-- posted at: 8:28pm EDT
Sun, 10 December 2017
Joe is down with OCP, Michael argues DRY, and Allen deletes our show notes as we dig into Components and Component Cohesion from Robert C. Martin's (aka Uncle Bob) Clean Architecture.
Direct download: coding-blocks-episode-71.mp3
-- posted at: 9:40pm EDT
Sun, 12 November 2017
We're back with another installment as we challenge ourselves to compare how we'd each spend $2,500 on developer gear as Allen waxes on about the loudest quiet keyboard, Joe teaches us how cheese is made, and Michael puts some neon on his computer.
Direct download: coding-blocks-episode-70.mp3
-- posted at: 11:52pm EDT