Category Archives: Refactoring

Encapsulation: Entities, Collections And Business Rules

Yesterday, I was involved two very separate yet very related conversations. One was via twitter with Colin Jack and Jimmy Bogard (which I was only a partial contributor to – mostly just reading their conversation) and another after work with … Continue reading 

Also posted in .NET, Analysis and Design, Design Patterns, Domain Driven Design, Model-View-Presenter, Principles and Patterns | 6 Comments

Dependency Inversion: ‘Abstraction’ Does Not Mean ‘Interface’

A coworker recently asked if we should always abstract every object into an interface in order to fulfill the Dependency Inversion Principle (DIP). The question stunned me at first, honestly. I knew in my head that this was a bad … Continue reading 

Also posted in .NET, Agile, Analysis and Design, Domain Driven Design, Lambda Expressions, Philosophy of Software, Principles and Patterns | 6 Comments

DI and IoC: Creating And Working With A Cloud Of Objects

A few months ago, I posted some thoughts and questions on the proper use of Inversion of Control (IoC) containers and the Dependency Inversion (DI) principle. Since then, I’ve had the opportunity to do some additional study and teaching of … Continue reading 

Also posted in .NET, Analysis and Design, Design Patterns, Principles and Patterns, Unit Testing | 6 Comments

Separation of Concerns by example: Part 5

In our last example, disaster finally struck our quaint little application.  A strange defect showed up, which would be almost impossible to reproduce back on our developer machine.  But because we’ve broken out our dependencies, our CustomerFinder became easier to … Continue reading 

Also posted in AntiPatterns, Principles and Patterns, Quality, RSpec, Test Automation, Testing, Unit Testing | 19 Comments

Separation of Concerns by example: Part 4

In the last part, we finally broke out the caching and data access concerns from our original class.  The series so far includes: Separation of Concerns – how not to do it Separation of Concerns by example: Part 1 – … Continue reading 

Also posted in Agile, Analysis and Design, Continuous Improvement, Productivity, Quality | 42 Comments

Entities and the Law of Demeter

The Law of Demeter, and its corresponding code smell, Inappropriate Intimacy, are some of the best bang-for-your-buck code smells that you can address.  The basic idea behind each of these concepts is code related to an object should probably be … Continue reading 

Also posted in Behavior Driven Development, Command Line, Git, Productivity, RSpec, Ruby, Source Control, Test Automation, Testing, Tools and Vendors, Unit Testing, Vim | 7 Comments

Separation of Concerns by example: Part 3

We made quite a bit of progress separating out the concerns in Part 2, but there are still some issues with our current design.  Other parts in this series include: Separation of Concerns – how not to do it Separation … Continue reading 

Also posted in Analysis and Design, Management, Pragmatism, Principles and Patterns, Security, Standardized Work, User Experience | 10 Comments

Separation of Concerns by example: Part 2

Separation of concerns is one of the fundamental tenets of good object-oriented design.  Anyone can throw a bunch of code in a method and call it a day, but that’s not the most maintainable approach.  So far, we’ve looked at: … Continue reading 

Also posted in Pragmatism, Product Reviews | Leave a comment

Separation of Concerns by example: Part 1

In the prelude to this series, I looked at a snippet of code that took the kitchen sink approach to concerns.  Here’s what we started out with: public class CustomerManager { [DataObjectMethod(DataObjectMethodType.Select, false)] public static List<Customer> GetCustomers(int startRowIndex, int maximumRows) … Continue reading 

Also posted in Analysis and Design, Pragmatism, Productivity, Quality, Risk Management, Testing | 12 Comments

Separation of Concerns – how not to do it

In a recent article on layered LINQ applications in the latest ASP.NET PRO magazine (no link, you have to pay), the author proposes separating your application into three distinct layers: User Interface (UI) layer Business Logic Layer (BLL) Data Access … Continue reading 

Also posted in Principles and Patterns, Product Reviews | 4 Comments