Naming stuff: Object Oriented Basics
Let’s look at Object/class design by example…
Have you ever designed a
data model (in code, Sql, or excel worksheets)?
Does the following look familiar?
*** anti-pattern - don't copy-paste *** * User - id - avatarUrl - name - email - password * Agent - id - primaryPhoto - name - email - agentEmail - agentPhoneMain - agentEmailPrimary - agentPhonePrimary - agentAddressFull - agentCompanyName - agentCompanyAddress - *userEmail* - 'Pointer' to User table ^^^
Where’s the bug?
Well, technically there’s no bug, simply data in need of re-organization.
Does the following sound familiar?
- Any change to your app will necessitate hours of arduous debugging.
- Any changing requirements will result in:
Why is naming a field
agentEmailPrimary so bad?
For starters, you are not creating an entirely new thing unto the universe. Over-specificity has some traps:
- ‘Locked’ into highly specific name, means
agentEmailPrimaryprobably make your views and related code 0% reusable, and featuring annoyingly recurring bugs like:
- Data not syncing between tables (not obvious if
user.emailneeds to propagate to
agent.agentEmailor vice-versa - nevermind complexity of manually implementing where & how to enforce this ‘logic’ …)
- Validation rules/logic are likely duplicated & inconsitent.
- Increasingly, your project will resemble a shaky Jenga tower.
- Fragility piles up with every single new file, as an extremely high attention to detail is required for even trivial changes
agentEmailPrimarycould mean a few different things. Avoid ambiguity with shorter names.
- Watch out for silly excess wording.
Primary? Just leads to more questions: Is there a Secondary? Is it for their Primary Next-of-kin?
Enough words Dan, what should it look like instead?
// Consolidated Schema: User - id - role: ['agent', 'lead', 'admin'] - name - phone - address - email - password - company - name - address
I removed the
Agent table, as it didn’t contain fields which were unique to Agents.
All changes were made with these general ideas in mind:
- Eliminate unessesary tables. If you have a few dozen tables, this step is mandatory.
- Try merge related tables. Important if you are coming from a SQL background to No-SQL
- Delete redundant data collection (e.g. remove
ActivityLogstable if replaced by Google Analytics)
- Try keeping all field names to a single word/noun/pro-noun.
- There is no such thing as
- By using Highly Specific Names, you cast-in-stone a specific level of
durability, well, specifically ZERO %.
- Don’t think you are doing yourself any favors with crap like this
User.profileSummaryEmail(where ‘profile’ could include contact details for a personal ads site) . This is probably a good point to create a new table, say
Recommended reading includes:
- Book: Code Complete