DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Waiting for the Abstractions to Emerge

Waiting for the Abstractions to Emerge

Mark Needham user avatar by
Mark Needham
·
Mar. 21, 12 · Java Zone · Interview
Like (0)
Save
Tweet
3.23K Views

Join the DZone community and get the full member experience.

Join For Free

One of the things that I’ve learnt while developing code in an incremental way is that the way the code should be designed isn’t going to be obvious straight away so we need to be patience and wait for it to emerge.

There’s often a tendency to pull out classes or methods but more recently I’ve been trying to follow an approach where I leave the code in one class/method and play around with/study it until I see a good abstraction to make.

More often than not it takes a few times over multiple days before anything reveals itself.

I recently watched Venkat Subramaniam’s Agile India presentation ‘How to Approach Refactoring‘ in which amongst other bits of advice he suggests that we ‘make it work then make it evolve‘ which sounds like it’s covering the same type of ground.

Sometimes in the rush to abstract code to make it easier to test or to reduce the size of a class we end up creating an abstraction which doesn’t really make sense in the business domain.

Having big methods of inline code goes against what we’ve learnt but putting all the code together makes it much easier to see the real abstractions in the code than if some premature abstractions have been made and we have to remember those as well.

It’s still useful to be driven by the goal of pulling out small classes of behaviour/data that are easy to test but spending a bit more time understanding the domain before doing so seems to work better.

We recently had some unwieldy code which we couldn’t quite work out how to abstract so we left the logic inline until we knew better even though it looked quite messy.

Eventually when talking to one of the subject matter experts they mentioned a term that they used which actually combined two things together which we’d originally thought were independent.

A simple rule of thumb is that if there is no name in the domain for what you’re abstracting then it might not make sense to do so.

It doesn’t always work but at least gets your thinking about whether you’re improving the code with the abstraction you’re about to make!

Abstraction (computer science)

Published at DZone with permission of Mark Needham, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • When Writing Code Isn't Enough: Citizen Development and the Developer Experience
  • Understanding OAuth 2.0
  • Are All Kubernetes Ingresses the Same?
  • Is DataOps the Future of the Modern Data Stack?

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo