Understanding and Identifying the
Responsibilities and the Dependencies
in Software Entities
There is great value in defining the Responsibility and the related Dependency requirements to support the purpose of a Software Entity.
A clear understanding of the “What” of a Software Entity is essential to developing code that will be easy to maintain over the life cycle of the code base.
Once the “What” has been clearly defined the task of creating a concrete “How” becomes a repeatable thought process.
An Enterprise developer has a responsibility to the rest of the team to create readable, clear and concise code.
The Code Must be Easy to Understand
… By all that Touches the Code
…… Throughout the Entire Code Life Cycle
A new developer viewing your design should be able to clearly understand the Responsibility of the code and the Dependency requirements of the design with the least amount of mental effort.
The Intent of the Software Entity Should be Very Clear
Best practice when creating a new object is to have a repeatable thought process that returns the answers to the following questions:
What is the Single Responsibility of this object?
– Single Responsibility – Create Apples or Oranges but not a Fruit Salad!
Is this object being created to manage State or Behaviour?
– State or Behaviour – Are we a Noun, a Thing, or a Verb, an Action?
Is this a “One and Only One” usage object or is it a candidate for reuse?
– Am I an Island unto Myself? – Will I ever have any Code Family Members?
What is the Inheritance Model: Class (Is A) or Interface (Behaves Like)
– My Inheritance Possibilities – How should I Behave in Public?
What is the likelihood of this object changing over its life cycle?
– Will I Always be Like This? – What will I Look Like in My Senior Years?
What are the Dependencies of this object?
– What are My Needs? – What do I Need to be Happy?
Great Developers Understand that their Work
… Is Only as Good as How it is Perceived
…… By the Next Developer who Touches It
You are a unique individual.
You must create a
reusable, specific, point by point thought process
that you engage every time
you type the name of your Software Entity
This will create continuity within your solutions and provide a signature to your art that others will begin to recognize.
Create a Professional Identity
that will Elevate You Above
the Average Developers within your Team
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services