Not every change that preserves system behavior is a refactoring. But every genuine refactoring, by definition, preserves client-facing behavior completely.
Tag: programming
If You Don’t Want to Be Replaced by a Robot, Don’t Act Like a Robot
Here’s a rant I’ve been sitting on, and it’s time to let it out. In the modern software development landscape, there’s an unsettling trend: we pretend that the perfect project flow is a conveyor belt, and the only thing slowing us down is “imperfect” specification. Every sprint, there are grumbles about user stories that aren’t… Continue reading If You Don’t Want to Be Replaced by a Robot, Don’t Act Like a Robot
Changing Object Types to Reflect State Transitions
In object-oriented design, objects encapsulate state and expose behavior that operates on that state. Consequently, if an object must exhibit different behaviors at various stages of its lifecycle, it can be beneficial to represent these transitions by changing its type. For example, consider a system that manages books. A newly created but unsaved book might… Continue reading Changing Object Types to Reflect State Transitions
The Interface Is Owned by the Client
This one is a less known principle, but with great implications. It is related to the Interface Segregation Principle, as well as to the Dependency Inversion Principle. It also dictates where interfaces should live in a multiple assembly architecture. This is going to be interesting, so hang on to your keyboards. What Do You Mean?… Continue reading The Interface Is Owned by the Client
The Single Responsibility Principle
Definition According to Wikipedia the Single Responsibility Principle is a computer program principle that states that “A module should be responsible to one, and only one, actor”. Robert C. Martin, the originator of the term, expresses the principle as “A class should have only one reason to change”. In my experience as an interviewer, I… Continue reading The Single Responsibility Principle
Softwarecraft 