Veloz

Hello

There seems to be lots of information out there on how to use good OO practices, principles and patterns, but it's not clear to me how far to go with these, and when.

It seems some people go full tilt with all projects. For example, I read one post where the author states his base classes are always abstract and he never programs to concrete classes, but to interfaces, and so on.

Others maintain that most of these practices are irrelevant until/unless you need to make a change to your program and find out that it's inflexible or hard to grow in a certain area. Or, of course, if you know up front that a part of your design will vary, then encasulate that part of the design.

I guess I'm looking for some advice on what a good rule of thumb is. Should you really always have abstract base classes, even if you can't imagine ever needing a different branch of your class hierarchy

Should you really delegate every part of an algorithm that you can possibly think of *just in case* you need a variation someday

I am currently working on my first application in .NET and have re-worked my design countless times.. sometimes feeling that my design is very rigid because all I have are concrete classes and only one place I can clearly see a need for some delegation .. and at others times feeling that for just two small use cases I have created an unwieldy amount of abstract classes, interfaces, and indireciton mechanisms.

Ugh!

Michael







Re: Architecture General How much OO is too much?

Yoni Rapoport

OO design is based on decoupling components by programming to an interface instead of programming to an implementation. This seperation is usually achieved through the use of polymorphism and design patterns. A design based mainly on concrete classes communicating directly is more procedural than OO.

I don't think OO has much to do with planning ahead to achieve flexibility. However, a design which uses abstract types and interfaces which minimize data flow and concrete type dependencies is more flexible as it is - whether it is designed with any future changes in mind or not.





Re: Architecture General How much OO is too much?

Martin Platt

Michael,

I think I'd always use OO concepts when designing code, although how normalised a particular entity is, and so forth would really be down to the problem domain, and what it requires.

My view is always use interfaces, as they afford you, with the inclusion of other patterns, to cleanly do things such as unit testing and such like. With Visual Studio and it's refactoring tools as they are, there's little extra to have to do to achieve that.

Keeping on revisiting your design sounds perhaps like you're unsure of requirements, or at least all of the requirements you might conceivably implement in your solution. In that instance, I'd probably use OO concepts, such as interfaces, MVP patterns, factories and the like to implement, as refactoring these is fairly straight forward - the neater the better. Then as you develop your application, you will also come to a great understanding of what works, how your requirements fit together, and so on, and can refactor the design to make it all work. My view on implementing everything just in case something changes, is that there's no point You might not need it, and if you don't, you're going to end up with a hugely overengineered solution, that's likely complicated and bloated, just in case. Instead, implement the minimum, using loosing coupling, and patterns where you think they may be appropriate. If in time you find you're wrong, or that something new has come to light, refactor, and implement.

Personally, have a look at what patterns and concepts people are using, then pick out what you think works, and is needed. You will over time develop your own style of design and development, to cope with future changes.

Good luck,

Martin Platt.






Re: Architecture General How much OO is too much?

J. Ambrose Little

Hi Michael,

To answer your specific questions, no, don't make everything an abstract base class. There is a very important agile principle to apply here called YAGNI--ya ain't gonna need it. Only solve the problems that you know you have.

Personally, I'd suggest not worrying too much about using interfaces or abstract classes. That puts the focus on an implementation detail when your focus should be on the problem domain. If you correctly identify the objects in your domain and get them the right behaviors, all this other stuff is just icing.

As a side note, I was in a class at SD Best Practices last week called "Human Factors in API Design." One of the assertions the presenter made was basically to not use inheritance unless you have to because it increases the complexity of your API (which he calls Application ProgrammER Interface Smile ) by orders of magnitude. He also had some less than friendly things to say about interfaces in general. I tend to agree--prefer finality (sealing) over open-ended classes and prefer classes over interfaces. These principles will simplify your model, making it easier to use, understand, and maintain.






Re: Architecture General How much OO is too much?

Yoni Rapoport

J

Interfaces and abstract classes are important elements of OO design. Describing them as an implementation detail is plain wrong. Perhaps the use of computer software is an implementation detail and we should focus on the problem domain of selling shoes instead...

Also, an API based only on concrete classes may be easier to understand for C programmers but I'm not sure this is true for programmers of OO languages.





Re: Architecture General How much OO is too much?

J. Ambrose Little

Yoni,


I thought about what you said, and I have to stand by my previous statements. Yes, you need to know what interfaces and abstract classes are and how to use them, but they are the mechanics (implementation details or tools) of OOD, not the core of OOD by any means.

Your exaggeration about focusing on the problem domain is more true than you realize. Most businesses (except for software companies) don't care about computer software per se, and they'd absolutely fall in love with you if you focused on their problem domain.

If your problem domain is helping a shoe company automate some portion of its business, then absolutely your primary concern should be focused on understanding, distilling, and modeling that domain as accurately as possible. Doing this the right way, which is the core of OOD, will put you far further down the path to success than worrying about using abstract classes vs interfaces vs concrete classes; I guarantee that your client couldn't give a rat's patoot about abstract classes as long as you deliver software that actually does serve its purpose well.

Lastly, it is patently obvious that concrete classes are easier to deal with than polymorphic classes. That, in itself, is a good enough reason to prefer them. I can only assume that you've never supported a widely-consumed API if you think that being concerned with minimizing exposure and maximizing ease of use is not important. Polymorphism has its place, but it is very easily abused, and there are still hordes of developers of "OO languages" who don't get it at all or struggle with it. Maybe you think they shouldn't be developers, but the reality is that they are. And we have to deal with reality.






Re: Architecture General How much OO is too much?

Yoni Rapoport

J

I think that while you are correct in the fact that most businesses use computer software as a mere tool, you should bare in mind that this forum deals with issues of software design and architecture and not the design of business processes. I assure you that just as your client doesn't care if you use abstract classes or not, she also doesn't care if you modeled the domain as accurately as possible or not - as long that you have produced running software which is able to automate the business process correctly.

So you claim that modeling a domain (which is an ambiguous term at best) is at the core of OOD, but domain modeling was being done long before object orientation ever emerged as a design methodology and can actually be done just as easily using other design methodologies as well. Encapsulation and polymorphism, however, are at the core of OOD, so by not following them as design guidlines you're not doing much OOD at all...

Regarding widely-consumed API's let me first state that what is good for API design is not necessarily good for non-API design. Designing and documenting every piece of your internal code as if it is going to be widely-used is a YAGNI. You claim that polymorphism should be avioded simply because it is hard but you are underestimating the benefits which make it worthwhile.





Re: Architecture General How much OO is too much?

Udi Dahan The Software Simplist

The kind of polymorphism I find most useful is having a top-level interface, with multiple concrete classes "inheriting" (i.e implementing) it.

I think that you are more describing OOA (OO Analysis) than OOD (OO Design) here, yet both deal more with the structure of the solution domain than, say, the way the UI looks, which seems to be more in-line with what you're talking about.






Re: Architecture General How much OO is too much?

Yoni Rapoport

Udi

I don't know of any other way to do polymorphism...

However, I think OO in general deals mostly with the structure and interactions of software runtime components (objects). Using OO techniques one can (and should) end up with classes which represent elements in the problem domain but this is a result of using encapsulation and polymorphism, not a cause.
By the way, the way the UI looks has much to do with the problem domain in terms of what data is being displayed how the user navigates and updates that data. The OO design process of UI components is very similar to that of business process applications in the fact that maintainability is the key to the success of both, and that is what OOD is trying to help us achieve.

This discussion started out with the question of whether OO design patterns are worthwhile using at all, do you think they are not





Re: Architecture General How much OO is too much?

Yoni Rapoport

Michael

I think a good rule of thumb is if you don't have at least two implementations for an interface or abstract class at the time they are defined then you shouldn't define them at all. This doesn't mean you should define a concrete class either, simply avoid delegation until you can come up with a way to split it into two concrete implementations (the GoF design patterns are a good place to look for such ways).





Re: Architecture General How much OO is too much?

Ollie Riches

In my experience inheritence levels that are any deeper than 3 become a maintainence issue. What I mean by 3 levels are interface, abstract class with common implementation, and concrete implementation class. Having this view means I believe that encapsulation of data and the definition of behaviour (on said data) is more important the abstraction.

Just my two pennies worth...

Ollie Riches






Re: Architecture General How much OO is too much?

Udi Dahan The Software Simplist

I think that anyone who has used OO design on a full project would say that it is worthwhile. It is my opinion as well. However, doing the "mind-switch" isn't easy and takes some time. I think it is best done under the mentoring of someone who's already crossed that bridge.

And, BTW, my previous comment was in response to that made by J. Just a little concurrency to make my day Smile






Re: Architecture General How much OO is too much?

Yoni Rapoport

Ollie - I can only add that my experience has tought me the same - having deep inheritance hierarchies is probably even worse than having no abstraction at all and it seems you've found the middle ground.

Udi - I agree with you completely, I just think that experts should not discourage programmers from learning and using advanced techniques. There is plenty of information on this subject and mentors to be found out there...





Re: Architecture General How much OO is too much?

J. Ambrose Little

Hi Yoni & Udi,

I appreciate both of your perspectives and think what you say definitely has truth in it. The thrust of what I was originally trying to communicate to Michael is that if you're focusing too much on whether to make something abstract or an interface or whatever, you're going to end up missing the real value of OOD. If you think that OOD is just about using these code constructs we call classes, interfaces, etc., you're missing the point. These constructs are formal representations of underlying concepts, ways of thinking about and analyzing the domain. They are the tools in the OOD toolbox that let you turn an object-oriented domain model into a running OO domain model.

And in fact, if you don't properly model the domain, you have a much more basic, core problem that you can't fix by choosing interfaces, abstract classes, or concrete classes. It's about first principles, really. On the other hand, if you do get the domain model right, then whether you use abstract classes, interfaces, or concrete classes is not as important, the choice will flow out of your good analysis and model. For me, it's about ensuring the focus of your immense intellectual power is in the right place.

I think that if the focus is right, the question of "too much OO" is moot. No, OOD is definitely the right way to tackle software, in my mind. But I think often when folks get frustrated with it and find themselves asking if OOD is the right way to go, it's because their focus is in the wrong place and they're not really deriving the real value in that approach to software development because they're too concerned with things like whether this particular thing should be an interface or a concrete class or maybe they're basing object identity on attributes instead of behaviors.

So again, I say, don't get too concerned about interfaces vs concrete. Don't let it become such a burden that it causes you to question the value of OOD.

Lastly, I hear what you're saying about going overboard in API design. I think you're attacking a straw man there. I would say, though, that while the APIs for an application have a lower acceptable standard, the same principles apply. You should design for clarity and ease of use regardless for your own sake (your later self returning to that code) as well for others who will need to support that code. And part of this is preferring concrete over abstract unless you have a good reason for the latter; Yoni's advice is right to the point here--if you're model tells you that you need abstract (e.g., you have more than one implementation) go that direction; otherwise, don't do it just for the sake of doing it.

Thanks all. This has been an enjoyable discussion.






Re: Architecture General How much OO is too much?

kawesa

I don't think procedural programming should be encouraged in any form at all, OOP is the way to go; I don't see too much use for abstract classes but interfaces are just good. The idea of OOP is structure, you build software from components rather than from linked up functions. You actually don't need me to tell the benefit OOP, it should be apparent.

Only entities that are relevant in the domain should be defined, you can use interfaces to link up characteristically related entities if it makes sense, without tightly coupling (tight coupling takes away flexibility). Benefits include code reuse, you always end up with less code and more code flexibility.

Generally, you should decide which objects are business objects which are controller and helper objects, business objects should reflect the domain entities, while the other two types of object can be intuitively designed to your needs.
I also suggest you do your analysis and design modeling using UML, it makes OOP much more meaningful with object models to capture requirements and architecture.

As everyone has already stated, use what you need, don't go on complicating simple projects, if you try to solve all the problems today you'll have no work tomorrow (and I'm not encouraging laziness).
Remember to comprehensively document your code always; unless you like playing archeologist.

Please tell me if I'm wrong, OOD is never too much.