E-R to OO design strategies?

I'm still learning all of the powers of OO design and have much more experience in database (in particular, E-R) designs. Each time I approach a problem and attempt to come up with a design following OO strategies, my diagrams(UML classes, for example) come out looking like an ERD. I've read/heard it's then smart to map a class to each table and work from there... But this never really seems to get me anywhere and my designs have very high (bad)coupling which, as I understand, is a big "no-no" in OO.

A few google searches returned a few hits on moving from E-R to OO, but nothing that really drilled it home for me. Does anyone have any materials on this topic, or have perhaps struggled with this similar problem?

To expand just a bit, my attempted OO designs tend to move toward开发者_开发问答s an implied persistent data storage element which doesn't necessarily exist in an OO design.

Thanks for any guidance!

Database Systems: A Practical Approach to... is the textbook(chapter 3~4) which I would recommend.

I think the fundamental differences in data(relational data model) and program are the main gap between E-R and OO design. You may draw database schema design in UML, but it doesn't mean that realational data model would become any sensible meaning of OO paradigm.

The programs, from another side, focus on processing correctly with reusability discipline. The data, however, focus on persisting correctly with performance discipline.

Although there are some techniques to ease the gap(lik O-R Mapping), but the basic purposes on data/program are not totally the same.

So I think the OO is just a technique to abstract the design, not the goal of the design.

I'd suspect from what you write that you need more experience with / knowledge about some core OO design principles, in particular inheritance and polymorphism. A good understanding of these concepts can help you better understand the relationships between your objects, and the ways in which they should be coupled.

Given your comments about your OO designs moving towards an implied persistent data storage element, you might also want to look into such concepts as Aspect Oriented Programming (Spring is a great tool for this). Also, look into what an ORM such as Hibernate can do, and how it does it (this may be a bit advanced, though).

There's really only one way to learn object-oriented software design: learn it from scratch. You won't find any shortcuts for converting your knowledge of another software design method into an understanding of object-oriented design. You need to start with the basics, just like everyone else: encapsulation, abstraction, is-a and has-a relationships, etc.

E/R concept model can help you whenever you need to design relationships between an entity. You shouldn’t care how they are going to be implemented at design time : the can be converted into Class,DataTable,XML,....

what you are asking it's a bit different. In a small system or when the business logic is not too complex it is possible to have a domain model object that looks like the Data Table.In this case you can have an object per table. This pattern is called "Table Module Pattern"

http://martinfowler.com/eaaCatalog/tableModule.html

Use Nhibernate or EF or any other ORM in a system like the one mentionated earlier it's a waste of resource and time because you are adding a layer that you don't really need