none
Sample or guideline for OO design

    Question

  • Is there any good sample or guideline for OO design? It's always hard for me to start over a new project that stick with all those rules. (Maybe I need a framework.)

    For example, I am creating a tender input Windows Form for my company POS system now. I produce my code by using different event handlers. The result is a piece of mess after many change request. I understand that the VS.NET will produce quick and dirty code. The UI and the business logic are tightly coupled together. There's no way for unit testing. (Maybe many more drawbacks) So, how can I overcome all this? I'm really tired of my current poor programming style and hope that I can find a better way to complete my task.

    Thanks in advance!
    Thursday, July 12, 2007 2:15 PM

Answers

  • You are actually asking about a lot of things.  Object-oriented design is the basic building block off which everything else builds.  Unfortunately, not many developers take the time to learn it (or even realize that it's there).  By simply asking this question, it tells me you are already on your way.  I was in the same position you were in not too long ago.  I wrote apps that worked but were hard to maintain.  I fell prey to completely rewriting my apps after a lot of business requirements changed (ie..6-8 months down the road).  The cycle of writing and rewriting applications plagued me and I hated it.  I ended up getting really fed up with myself and my profession--always wondering why things turned out that way.  I wondered if it were really that hard and thought about switching professions.  Then I asked the same question you just asked in this post. 

     

    Looking back, I can tell you now that it's not that hard.  Learning OOP is the first step (and a step that most people don't even see).  Most people don't realize you can break the vicious write/rewrite cycle and they don't know how much fun it is to work on an application which was built to be maintainable.  So, that being said, you are definitely on the right track.  Seeing the problem is HUGE.  Congrats! ;-)

     

    Now, let me show you a few things to help.  First, one of the best places to grab information about object-oriented design principles is from the Object Mentor website:

    http://objectmentor.com/

     

    It's a website that's run by one of the best Agile/OOP guys out there, Robert Martin (also sometimes called "Uncle Bob" Martin).

    Specifically, I encourage you to check out his "published articles".  The really good stuff is under the "Design Principles" topic.

    http://objectmentor.com/resources/publishedArticles.html

     

    Learning the basic OOP priniciples will put you ahead of at least 90% of the .NET developers I personally have encountered.  Here's a simple way to remember the most important OOP principles: SOLID

    S) Single Responsibility Principle

    O ) Open/Closed Principle

    L ) Liskov Substitution Principle

    I ) Interface Segregation Principle

    D) Dependency Inversion Principle

     

    Memorize each of these principles and watch your code quality go through the roof.

     

    Next, take some time and study the basics of application architecture.  I highly highly recommend getting a copy of Martin Fowler's "Patterns of Enterprise Application Architecture".

     

    It will show you the common ways people layer their applications, access the database, etc.  In a nutshell, it will tell you the common ways people take their objects and organize them into a well-built application.

     

    Another highly recommend thing to learn is to pick up an Object-Oriented Design Methodology.  People often talk about Software Development Methodologies (ie.. Agile, Waterfall, etc), but rarely do you hear people talk about Design Methodologies.  This will give your code another huge boost in quality.

     

    Two in particular I can recommend:

    "Domain Driven Design" by Eric Evans

    "Applying UML and Patterns" by Craig Larman

     

    The first teaches the Domain Driven Design methodology.  The second teaches the Responsibility-Driven Design methodology.

     

    From there on out you will be a rockstar developer with mad OOP skills and a budding software architect.  I would suggest polishing yourself off with Test-Driven Development (which kills 99.999% of the bugs in your code) and a good study of Agile Software Development and Patterns.

     

    Looking back, all my frustration with software development is gone.  I can now honestly say that I love what I do.  I also enjoy helping others find the path that has been so rewarding for me.  All the learning is not easy, it's work.  But it's ooo soo worth it. ;-)

     

    To close this long response off.  In response to the question you asked, let me ask you another question. 

     

    "This is your last chance. After this, there is no turning back. You take the blue pill, the story ends, you awake in your bed and believe whatever you want to believe. You take the red pill, you stay in Wonderland, and I show you how deep the rabbit-hole goes. Remember: all I’m offering is the truth, nothing more."

    Thursday, July 12, 2007 10:13 PM

All replies

  • The best example and framework for .NET that I know of is Rocky Lhotka's CSLA.
    Thursday, July 12, 2007 2:53 PM
  • Is it suitable for a beginner like me? Is it difficult to pick up. Moreover, is it difficult to migrate my current dirty code into this framework? A reasonable level of code re-write is acceptable.
    Thursday, July 12, 2007 3:18 PM
  • Hi

     

    First off, if you have messy code now, no framework will come and magically save the day...

    You really need to sit down and (re)design the application to see what level of rewrite you are talking about...

     

    For design guidelines and so on, check out software design patterns..

    www.martinfowler.com

    www.dofactory.com

    http://en.wikipedia.org/wiki/Design_Patterns

    ...

    these will help you in creating a global architecture for your application

    more low level you need to decide and the roles and responsabilties of the objects in your code

    http://www.amazon.com/Object-Design-Roles-Responsibilities-Collaborations/dp/0201379430

    I

    I know that this is very "general", but OOP is harder than it seems,

    and all too often OOP is reduced to using this or that framework...

     

    I hope this at least points you in the right way...

    good design comes with experience i'm afraid...

     

     

     

    Thursday, July 12, 2007 8:33 PM
  • also,

     

    a note on unit testing:

    there is unit testing support in visual studio (i think ms unit testing exists from professional visual studio onward)

    if you are using an other version: try www.nunit.org

     

    furthermore, the high coupling can be avoided by abstracting your services (business logic) into another assembly and exposing it by interfaces only...

     

    Hope this helps you out

    Thursday, July 12, 2007 8:37 PM
  • You are actually asking about a lot of things.  Object-oriented design is the basic building block off which everything else builds.  Unfortunately, not many developers take the time to learn it (or even realize that it's there).  By simply asking this question, it tells me you are already on your way.  I was in the same position you were in not too long ago.  I wrote apps that worked but were hard to maintain.  I fell prey to completely rewriting my apps after a lot of business requirements changed (ie..6-8 months down the road).  The cycle of writing and rewriting applications plagued me and I hated it.  I ended up getting really fed up with myself and my profession--always wondering why things turned out that way.  I wondered if it were really that hard and thought about switching professions.  Then I asked the same question you just asked in this post. 

     

    Looking back, I can tell you now that it's not that hard.  Learning OOP is the first step (and a step that most people don't even see).  Most people don't realize you can break the vicious write/rewrite cycle and they don't know how much fun it is to work on an application which was built to be maintainable.  So, that being said, you are definitely on the right track.  Seeing the problem is HUGE.  Congrats! ;-)

     

    Now, let me show you a few things to help.  First, one of the best places to grab information about object-oriented design principles is from the Object Mentor website:

    http://objectmentor.com/

     

    It's a website that's run by one of the best Agile/OOP guys out there, Robert Martin (also sometimes called "Uncle Bob" Martin).

    Specifically, I encourage you to check out his "published articles".  The really good stuff is under the "Design Principles" topic.

    http://objectmentor.com/resources/publishedArticles.html

     

    Learning the basic OOP priniciples will put you ahead of at least 90% of the .NET developers I personally have encountered.  Here's a simple way to remember the most important OOP principles: SOLID

    S) Single Responsibility Principle

    O ) Open/Closed Principle

    L ) Liskov Substitution Principle

    I ) Interface Segregation Principle

    D) Dependency Inversion Principle

     

    Memorize each of these principles and watch your code quality go through the roof.

     

    Next, take some time and study the basics of application architecture.  I highly highly recommend getting a copy of Martin Fowler's "Patterns of Enterprise Application Architecture".

     

    It will show you the common ways people layer their applications, access the database, etc.  In a nutshell, it will tell you the common ways people take their objects and organize them into a well-built application.

     

    Another highly recommend thing to learn is to pick up an Object-Oriented Design Methodology.  People often talk about Software Development Methodologies (ie.. Agile, Waterfall, etc), but rarely do you hear people talk about Design Methodologies.  This will give your code another huge boost in quality.

     

    Two in particular I can recommend:

    "Domain Driven Design" by Eric Evans

    "Applying UML and Patterns" by Craig Larman

     

    The first teaches the Domain Driven Design methodology.  The second teaches the Responsibility-Driven Design methodology.

     

    From there on out you will be a rockstar developer with mad OOP skills and a budding software architect.  I would suggest polishing yourself off with Test-Driven Development (which kills 99.999% of the bugs in your code) and a good study of Agile Software Development and Patterns.

     

    Looking back, all my frustration with software development is gone.  I can now honestly say that I love what I do.  I also enjoy helping others find the path that has been so rewarding for me.  All the learning is not easy, it's work.  But it's ooo soo worth it. ;-)

     

    To close this long response off.  In response to the question you asked, let me ask you another question. 

     

    "This is your last chance. After this, there is no turning back. You take the blue pill, the story ends, you awake in your bed and believe whatever you want to believe. You take the red pill, you stay in Wonderland, and I show you how deep the rabbit-hole goes. Remember: all I’m offering is the truth, nothing more."

    Thursday, July 12, 2007 10:13 PM
  •  

    Personally, I wouldn't recommend getting straight into a framework if you don't know how to use OO principles to design, I think if you do, you may end up in a different mess, with a whole new load of framework that you don't understand also.

     

    It sounds like you need to set up some tests, to make sure that the requirements of the system are taken care of, and every time you get a new bug, add tests to make sure that they never happen again.  At least you can move forward with your project regardless of how you design the code.  That will at least buy you time, since I'd imagine the reason for the posting is because you're under pressure to deliver the solution.

     

    I think I'd then get reading various sources, look through the various code sites out on the net, read books, and learn.  In time, you will be able to safely re-factor your code to use OO (in fact, I'd expect that to happen largely as a result of writing tests)

     

    I think whatever framework you use, including the .NET framework itself, it is very easy to misunderstand, and abuse the potential effectiveness of its use.

     

    Good luck!

     

    Martin.

    Thursday, July 12, 2007 11:24 PM
  • To answer the question, Rocky has written a book about the framework as well, and it will introduce you to the concepts as well as use his framework as a concrete example.  The problem with all these people (not necessarily those here, just in general) pontificating about different design approaches is that few of them take the time to turn the ideas into a concrete and thorough implementation that can serve both to learn from and to actually use.  Rocky has done that with CSLA, and that's why I recommend it as the best OOD example and framework for .NET that I know of.

    You can definitely read some other stuff as has been recommended; it will only help.  But in terms of most bang for your time, I think that CSLA will be a good investment due to its concreteness.

    Thursday, July 12, 2007 11:52 PM
  • Thanks for all the input. I will grab some books and then start my programming learning path from the very beginning again. Thanks again!
    Friday, July 13, 2007 3:18 AM
  • You can read a little on the principles Evan mentions in a paper I wrote called "OO Primer"
    (and there's also a presentation)

    Arnon
    Friday, July 13, 2007 8:29 PM
  • OO Design principles and decent C# design patterns

    Saturday, June 14, 2008 10:26 AM
  • If you want to decouple the business logic from the UI you could use a design pattern like Model View Controller, Model View Presenter or Mediator.  This will help with the messy code and enable you to use the unit testing framework that comes with Visual Studio.

     

    Organising the application into layers of responsibility will help to make the code clearer and more testable.

     

    For an overview of OO design principles I would read 'Agile principles, patterns and practises'

    Monday, June 16, 2008 1:53 PM