BVSP
A Software Entity should not Manage
both Behaviour and State
as the same Responsibility
BVSP Abstract:
The knowledge of the difference between State Objects and objects that expose Behaviour of the Software Entity for the underlying application is essential for creating manageable objects.
This design principle supports a lower cost of maintenance throughout the Software Development Life Cycle (SDLC).
Description:
Software Entities are any Object in C# that manages State or Behaviour.
All entities in C# are derived from System.Object
… All Objects have a “Responsibility” to Perform some Work
An object that manages State is generally a noun.
It is a “Thing”, as in “Person, Place or Thing”. It uses an English grammar Noun.
An object that manages Behaviour performs an action, as in “Conveys an Action” and uses an English grammar Verb.
The Developer’s Naming Convention
should clearly define the primary responsibility
of a Software Entity: State or Behaviour
It is important to understand the difference between State and Behaviour as it relates to C# objects.
State objects perform no actions other than initializing its current attributes values.
What are State and Behaviour Objects?
The Following C# Objects are State Objects:
- Integral Types
- Floating Point Types
- Decimal Types
- Boolean Type
- Enumerations
- Strings
- Data Members
- Properties
- Data Transfer Objects
The Following C# Objects are Behaviour Objects:
Methods perform actions that result in some Behaviour change.
They can act as a Function and return Null or create another object as a return type.
Make sure your Methods are lean and produce Behaviour within a Single Responsibility.
Use refactored Helper Methods from Class Methods to encapsulate Dependency functionality for use in the Class.
This allows the Just in time (JIT) compiler to make performance decisions on how to present the code to the Common Language Run-time (CLR).
Internal Helper Methods can be loaded into Managed Heap “Registers” with pointers.
These Methods will only be compiled when actually called into use.
A single Register can manage a large number of Methods without creating additional memory blocks on the Managed Heap.
If the Helper Method is a “One and Only One” usage in the Class make it Private.
If it is a candidate for reuse, refactor it into an Architecture Layer Common assembly for reuse in other Objects as Public access.
An Interface can contain Properties, Methods, Indexers and Events.
It defines a concrete contract that any Class or Strut that implements it must follow.
It contains no concrete implementation, only the “Signature” for the implementing Class to use.
When only “Interface Like” signatures are created in an Abstract Class it consumes the single inheritance option that is available to every Class.
It changes the relationship from an “Is A” to a “Behaves Like” relationship.
It becomes a Class Interface that performs, at run-time faster than a traditional Interface.
When concrete Behaviour are included in the Abstract Class the “Is A” relationships implements the Contract signatures to create a “Contract of Behaviour” in all derived Classes.
Any Behaviour Object that complies with the Delegate signature that has registered to be notified of the Raised Event will be executed.
Events create dynamic Behaviour.
By clearly understanding State and Behavior
along with the
Single Responsibility that the Dependencies
require to carry out the objective
you will be working smarter
Your efforts will create more elegant solutions.
The people who use your code will love you and want to buy you lunches 😉
Latest posts by Brad Huett (see all)
- DevOps: A Bridge to Your DevOps Culture - March 25, 2016
- Embracing Test Driven Development (TDD) - March 25, 2016
- DevOps: Delivering Agile Projects - March 25, 2016