views:

298

answers:

8

When given an example of refactoring, I'm tired of seeing a Data Access Layer with string literals for connection strings being replaced by IConnectionStringProvider.

eg:

public DataSet GetCustomers()
{
    string connectionString = "SQLClient;Blah;Blah";

    using(SqlConnection conn = new SqlConnection(connectionString))
    ...

to this

public DataSet GetCustomers()
{
    string coonectionString = connectionStringProvider.GetConnectionString();

    using(SqlConnection conn = new SqlConnection(connectionString))
    ...

In the Domain Driven Design world I'm tired of seeing the Domain be a Customer who has many Orders which also has many OrderLineItems. Please explain Aggregate Roots using something a bit more interesting please!

Or am I completely losing it and rehashing these simplistic is the best way to teach these ideas?

Ooh, and using shapes to explain inheritance...

What examples to you use to teach these concepts?

+1  A: 

I remember reading of OOP with examples of a Car or Bicycle extending a Vehicle, all having a steer()-method (or something similar)

Henrik Paul
A: 

I remember the Employee, Manager example in OOP and in Database design.

Techmaddy
A: 

Duck.Quack();

Martin
You leave DuckSimulator alone :p
Pondidum
+1  A: 

The OO one of having a House object, containing several Window objects and a Door object being too abstract to be useful.

And yeah the vehicle related one isn't so good either.

The question to think here is "what do I want the people reading this to learn?" If you're trying to get people to learn about objects and inheritance, then do it using real examples that make sense.

So a dialog object, containing several button objects and a textbox object is a much more realistic idea and no more complex to understand - everyone has seen a dialog box before. This can then be refined into a generic 'window' object, of which buttons, textboxes and dialogs are subclasses.

This would then conveniently lead onto creating a real, working piece of code, rather than filling the reader's head with abstract theory and then seeing if they can make the mental jump to real world concepts.

Piku
A: 

for the inheritance in OOP, i'd usually go with a quadrilateral. extend it to make square, rectangle, ... extend square to make a cube, rectangle to make a cuboid ...

Sujoy
+2  A: 

As someone who does a lot of phone screens, I am tired of hearing about Shape being the base class for Square and Circle. We need some more independent thought when it comes to discussing class hierarchies and interfaces.

Steve Rowe
+1  A: 

Class factories / Builder Pattern.

Especially the many articles about convoluted template stuffery to put the pattern into code once and for all. I mean, yeah, it can be done, it is a useful pattern but it's not the holy grail. It's an object creating objects. With interfaces. And parameters. And stuff.

Blargh.

peterchen
+2  A: 

I'm tired of seeing functional-programming advocates show how "quicksort" can be implemented in one line in Haskell, OCaml, F#, Scheme, etc. The "quicksort" that they show is not really Quicksort, because it is not swapping elements in place, and is doing all sorts of list construction and garbage collection. Doing a real Quicksort in a functional language is really messy.

Makes me wonder what else they are lying about.

Kristopher Johnson