Thoughts: Testing Without Mocks

James Shore has a post, Testing Without Mocks, that I've recently been introduced to. Skimming through the introduction of the post, it looks like the goals of this align well with what MicroObjects give us in terms of testability. I'm going to go through the article and post my thoughts…

Technical Practice: Objects avoid Primitive Obsession

I have a GitHub project FluentTypes which I've written about before. The goal is to avoid the problems of Primitive Obsession. We want to represent what we're thinking. After working in MicroObjects style and using the style represented by the Fluent Types; I found a new way. To my credit,…

Refactoring Legacy Code: Remove future proofing

The legacy code I'm playing with at work had some nice future proofing. It wasn't quite big design up front, but it was some future proofing. I got some out, but there's still a whole level of abstraction that's pending removal. I'm not here to write about what I haven't…

Refactoring Legacy Code: Leave Tested Methods Public

When refactoring from a large to small API, use interfaces for the new methods, but leave the old public IFF they are well tested. Its not worth re-working all the tests when they're hidden by using the interface This is a short little post about a small thing I did…

Refactor Legacy Code: Pass The Bigger Thing

Working in legacy code makes it clear how important refactoring is to maintainability. I'll go so far with the importance of Refactoring to say, "If the code isn't refactored, it isn't maintainable." Clearly I think this is a huge thing. One of the definitions of "Legacy Code&…

Refactor Legacy Code: Reduce DataBags

What is a DataBag? I consider a databag any object that primarily acts as transportation for data. In C++, this would be a struct. Ignoring any associated functions, the data's exposed and being passed around. Java would represent a databag by a class with primarily get/set methods around data.…

Antipattern: UI Databinding Android

This is me going through the Android recommendations on how to do databinding. As with A LOT of practices that increase the complexity and harm maintainability; databinding and the recommendations enable, perceived, QUICK development, but it has such a high cost afterwards; there WILL be re-writes. It won't be refactorable…

Antipattern: UI Databinding

I started this EARLY into my adventures gettign to understand what Object Oriented Programming is. The UI is always a rough part of the experience. I found some effective ways to deal with it. My latest way is to have the UI do nothing. There are ways to make it…

Technical Practice: No Inheritance

I've written before about the technical practice of composition over inheritance but what about the idea that we have NO inheritance? I use inheritance VERY infrequently. I have two cases where I use inheritance. Only when there is clear duplication between classes. I'd have to copy and paste the same…

Patterns: Chain of Responsibility

The Chain of Responsibility is one of the major patterns I use in my MicroObject projects. When I have a sequence of events, applying the practices forces things into a very narrow set of forms. I've found one that I feel is the clearest, cleanest, and most inline with the…