Category: Development Agility

Migrating the blog: Scott Bain

Thank you for joining us on this journey!

You may know that Net Objectives has joined with Disciplined Agile and is now part of the Project Management Institute. Here is the press release: https://www.pmi.org/about/press-media/press-releases/project-management-institute-announces-acquisition-of-flex-from-net-objectives

As part of this migration, Scott is now blogging on ProjectManagement.com. Here are the addresses of his blog:

We invite you to join in following him on that site.

On 30 September, the Net Objectives Thoughts blog will be officially closed.

If you have any questions, please contact Scott at scott.bain@pmi.org

Practice: Encapsulate by Policy, Reveal by Need

Traditionally, encapsulation has been thought of as the hiding of data or “state.” While it is true that hiding data encapsulates it, encapsulation can mean much more than this. It’s like the notion that all dogs are mammals, but not all mammals are dogs. Continue reading “Practice: Encapsulate by Policy, Reveal by Need”

Practice: Programming by Intention

Programming by Intention is a way of writing code that capitalizes on the way a programmer thinks.

Whenever you write code, what you are essentially doing in breaking down a behavior into its steps. In sense, that’s what code is. So, your brain, as a developer, is good at this. Programming by Intention says let’s capitalize on this fact. Continue reading “Practice: Programming by Intention”

Practice: Encapsulating Constructors in Simple Classes

A recurring question in OO is, “When it is determined that an algorithm should be established in its own separate class (to make it testable, or reusable, or simply as an issue of cohesion) should it also be given a separate abstract type that it implements?”

The advantage, of course, is that the client (or clients, as more arise) will not couple to the specific service class, but rather to the abstract type. If more versions of the service are added, then clients will be largely unaffected. It’s a form of “future proofing”. But can you do this all the time? Should every class, when deemed necessary, also have a second class that hides its real type? Often this would seem like overkill or over-design. Does that mean it should never be done? That seems wrong too.

Is there something that can be done to resolve this conundrum?

Continue reading “Practice: Encapsulating Constructors in Simple Classes”