I can't create a clear picture of implementing OOPS concepts, though I understand most of the OOPS concepts. Why ?

Question

I have been working on some of the projects of my own and dont have any indrustial exposure. Currently i use simple approach for developing small applications with negligible OO approach like creating a common class for database functions using polymorphism of functions little bit use of constructors but i dont really able to think of how to implement whole project logic using OOPS.

I know what are interface, abstract class, sealed classes and other oops concepts and very much clear picture in mind. But problem is that when and how should i implement OOPS heavily where I should.

Do i need to study real time applications and their case studies, if so please refer me some sites or books/e-books from where i can read them and can be able to implement them.

Currently i feel myself incomplete while programming. I implement database and most of its components effeciently, but a kid while trying to use OOPS.

I have read many examples that tries to make one understand OOPS like shape eg, car eg. all these kind of. They r gud to clear concepts but not enough to implement in some live project

Answer 1

It is a hard problem this - good OO design only becomes second nature once you've got the experience of building real-world applications, having to change them, being forced to re-appraise your original designs and so on. The problem is compounded by most examples being utterly trivial.

The best thing I can suggest is if you search for implementations of design patterns. These won't always provide non banal/trivial examples, but it will help to recognise the application of OO principles when you see them in other peoples' software. The other thing you could do, is try to create a real implementation of a series of common patterns yourself. Then when you're writing a production application, hopefully you will be able to make the connection and apply the relevant pattern / principle / design technique.

In short, there's no subsititute for experience.

For real code, I'd start looking at some projects that interest you on somewhere like codeplex.

Here's the classic list of GOF design patterns.

Here's a few examples of common patterns:

• Provider Model 1
• Provider Model 2
• Strategy Pattern
• Observer Pattern
• Abstract Factory

Answer 2

I believe what you are looking for is Object Oriented Design Patterns. Often many of the best OOP principles are implemented in standard design patterns which can be used in many types of projects.

Many developers when looking at a problem will attempt to fit it into a standard design pattern, which when used correctly speeds development!

I'd suggest reading up on object oriented design patterns and how they can be applied. A good example of this is the use of Abstract classes or interfaces in the Factory method pattern.

Wikipedia (http://en.wikipedia.org/wiki/Factory_method_pattern)

Answer 3

At first I would recommend this classic book on design patterns. http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr%5F1%5F1?ie=UTF8&s=books&qid=1261679601&sr=8-1

But in the end, all that really matters is working experience on big real-life projects! When you start working, and after a few years, everything will become much clearer.

Answer 4

The first step in learning to apply OOP is to gather common funcitonality and data into classes. You will not do a great job at first, but you will get better. A recent article in Code Magazine about getting back to basics expresses this well.

Start attempting to make (classes that will become) real objects that represent real things in your solution. (There a fancy name for this, but it's also very basic.) This is NOT making utility classes of handy, thematically related functions. Try to arrange things so that the data maintained in your objects saves you parameters when calling methods on that object. Think of the objects that will exists as real individual things in a community. Personify them. Arrange things so that you're not worried about what's going on in the classes while you're using their functionality.

I would not worry about all these design patterns at first. Better to first practice the basic OOP concepts that you have learned. Focusing on these patterns causes a lot of people to skip really thinking about the philosophy of OOP and instead try to jam their situation into a pre-packaged plan. Read about "design patterns" for entertainment and ideas. Later, you'll want to really study them and attempt to specifically implement some of them.

In short, you have to jump in and start applying what you have learned. You need to make some poor designs before you make some good ones, so don't worry about it.

Edit in response to comment from questioner: I think the next step might be to concentrate on the relationships between your classes. Once you are using a Customer object in your logic, for example, you should have to spend No Effort getting the related Order object. Make a property oCustomer.Orders, that returns List<Order>. (This is a c# example.) In this property get all that customer's orders, put them in list object, maintain it in a private variable in case the property is called again, and return that list object. If you have already done this, look for the next hardest new thing to try. Perhaps you need to often find the date a customer first made an order. Then, create an Orders class that inherits from Collection<order> to replace your basic List<order>, and add the property FirstOrder. You can then do var FirstOrderDate = oCustomer.Orders.FirstOrder.OrderDate.

Keep trying to do the next hardest new thing. Inherit and add members. Make a base class with child classes. Override base class members. Use and get good with custom collections.

Learn from the object models you are using. When you see something intuitive and easy to use, do like that! Early in my career I had to extensively use the MS-word object model, which was intuitive and easy. When I made my own libraries, I tried to duplicate that feel; the results were good.

Eventually study the patterns. As much as I advise that you not be over-awed by them, they are a great source of ideas and most importantly stuff to try out. (Knowing the names of common "patterns" is good for communication purposes also.) For example, when you see the plug-in model, the concept of interfaces will really make sense.

Answer 5

First off, i'd just like to recommend you use OOP instead of OOPS, partially because OOP is a programming paradigm so the 'System' part isn't really necessary (but of course this is only an opinion), partially because most people recognize OOP easier, so what you want is more explicit, and partially because OOPS makes it look like Object Oriented Programming is a mistake (hehehe just kidding). Of course, this is only my opinion, and i could be wrong of course.

Anyway, on to business. I think you are having problems because you are over-thinking at the start of your planning phase. Stop thinking about the methods and attributes each object has. Don't think about how it might be useful or how you are going to use it. Forget about the computer and how you are going to implement it. Just list whatever object comes to mind. You mentioned making a database application. You can start with what data you want to save. If you are going to make a database of students, for example, you would probably want to make a Student object. You would also need a way to connect to the database, so you would probably want an object to serve as a connection to the database. Of course, these two objects are just suggestions, and it's up to you whether you wish to use them.

After making a long list of objects, start looking at the objects you've made and list down what they do. Just because an object doesn't do anything, doesn't mean you should remove it from the list. Take the 'Student' object for example. It is there to store data about a certain student. If you know the C programming language, you can think of the 'Student' object as a struct. Once you finish this list, try and combine objects that seem really similar. Drop the objects that don't have anything to do, passively (like storing data) or actively (like connecting to the database, or getting user input). You should have your objects, and a majority of their attributes and methods. All that is left to do is implement these objects and add more to the functionality.

To further understand this, i recommend reading on Entity-Relationship Diagrams. That should help you in your design. Because i believe you are over-thinking things, i suggest not reading into patterns and GOF just yet, because it may just confuse you even more, and make you take more time to discover what to do.

This is merely my opinion and would really appreciate any comments and corrections cause i wouldn't wanna make this guys head go FUBAR hehehe

Answer 6

One moment when things clicked for me was reading "Test-Driven Development, by Example", by Kent Beck. The whole first part of the book is a walk-through of Beck designing a piece of functionality, step by step. I found it very helpful because you see the process happen in an organic way - starting with very few classes, which evolve over time.
I think starting with patterns is not necessarily a good idea. Design patterns are great, but I find that why they are useful becomes apparent only after having done it wrong on a real-life project first, and gained a sense for what works and what doesn't in OO.