vb.net - refactoring a field into a property -
i learning vb.net new job , have mixed feelings on public fields. see many arguments them hurting encapsulation. in python, common practice keep things simple , use fields when enough. if want add logic later, refactor them property without breaking client code.
in codebase working see huge classes containing dozen of properties like:
private __getdescriptionmode boolean <defaultvalue(false)> _ public property getdescriptionmode() boolean getdescriptionmode = __getdescriptionmode end set(byval value boolean) __getdescriptionmode = value end set end property
that's 10 lines of code little value inside. can barely see 3 of them in visual studio window. have 2 questions:
- is there valid reason not define fields , refactor them properties when needed?
- are oop principle important sacrifice readability? (i can @ fewer things, have parse property make sure are'nt doing special, etc)
edit clarify first question: have chance of breaking client code if change field trivial property?
it idea create properties rather fields.
- you can break client code if change public field public property.
- you can use data-binding properties.
- fields can't used in interfaces
- you break binary serialization code if change public field public property.
- if using reflection, changing field property later break reflection code.
read more blog post vb.net team, or jon skeet same issue in c#
in visual basic 2010 , later, use auto-properties
public property getdescriptionmode boolean
Comments
Post a Comment