Too much abstraction? 1

[dinger2121]

Hello,
I am trying to get my hands around true oop development, and am wondering if I am abstracting too much. I am a lone developer working on multiple projects. I currently have to do some work acquiring different dates given a particular date, ie, next saturday or sunday 2 weeks ago.
Since both of the examples above, and most other functions that I have to use, will take a date as input and then return a date value, should I create an interface and then make each function an implementation of that interface? or is that too much abstraction?
On top of that, should I create a date utility project so that I can isolate all of these date functions together, or is that overkill? would I be better off just putting what I need for a specific project directly in that project and just creating seperate classes for each?

Thanks for any thoughts.

carl
MCSD, MCTS:MOSS

 

[jmeckley]

carl, to answer the first part, yes you can have too much abstraction. One of the driving forces for abstraction is to encapsulate/isolate what changes.

Another force that will drive abstraction is complexity. If you have a small application with a few UI screens and some database calls, then abstracting Forms, Presenters, Services, Repositories and Data Access may be overkill. the abstractions could be as simple as Forms, Presenters, Data Access. For example controllers on my projects can look like this

class MyController
{
   private readonly ISession session;

   public MyController(ISession session)
   {
       this.session = session;
   }

   public void Index(...)
   {
       PropertyBag["key"] = session.CreateQuery("from Entity where ...").List<Entity>();
       RenderView("View to Render");
   }
}

Specifically addressing your date calculations; depending on the complexity of the calculations encapsulating the functionality within a extension method (or static function for 2.0) would work just fine. for example

public static void DateExtensions
{
   public static DateTime Last(this DateTime date, DayOfWeek day)
   {
      var current = date;
      while(current.DayOfWeek != day)
      {
          current = current.AddDays(-1);
      }
      return current;
   }

   public static DateTime Next(this DateTime date, DayOfWeek day)
   {
      var current = date;
      while(current.DayOfWeek != day)
      {
          current = current.AddDays(1);
      }
      return current;
   }

   public static DateTime LastSaturday(this DateTime date)
   {
      return Last(date, DayOfWeek.Saturday);
   }

      public static DateTime LastSunday(this DateTime date)
   {
      return Last(date, DayOfWeek.Sunday);
   }

   //repeat LastX for Monday - Friday
   //create methods for NextX as well
   // all of this are just convenience methods for Last(date, day) and Next(date day)
}

you can then use these function like this
[/code]
//sunday 2 weeks from today
var sunday = DateTime.Today.NextSunday().NextSunday();

//last Thursday
var thursday = DateTime.Today.LastThursday();
[/code]
by creating the simple single unit operations, we can compose them together to create more complex logic.

for example. if you need Sunday 2 Weeks From today a lot, then create an extension method using the blocks above

public static DateTime SundayInTwoWeeks(this DateTime date)
{
   return date.NextSunday().NextSunday();
}

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259

 

[dinger2121]

Thanks for the tip. I think I have been going a little overboard with what I am doing. I will scale it back a bit.


carl
MCSD, MCTS:MOSS

 

[jmeckley]

that is the natural progression of craftsmanship.
first you don't know what OOP is and all/most of your code is procedural.
then you learn about OOP, patterns and design and apply it to everything. your projects end up with more factories and strategies than actual business logic.
as time progresses you learn where to apply abstraction, when it makes sense to use the [X] pattern or not.

simply asking the question is growth from journeyman to craftsman.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259

 

[dinger2121]

Thanks - I've heard about that book but haven't had an opportunity to pick it up yet - I will add it to my reading list.

carl
MCSD, MCTS:MOSS