Quantcast

Maximum PC

It is currently Sat Dec 27, 2014 8:53 pm

All times are UTC - 8 hours




Post new topic Reply to topic  [ 11 posts ] 
Author Message
 Post subject: Design Patterns
PostPosted: Tue Aug 10, 2010 7:21 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
Anybody here know or keep up with design patterns? I started learning about them at the start of my programming career but never really paid attention to them. Now, I'm reading up on them and learning about them but I noticed a an oddity:

In OOP, inheritance/extension is a key component of sharing behavior between classes. However, with design patterns, it kind of shies away from inheritance proper (at least as a key fundamental of OOP). I could be wrong.

What do you guys think? Chime in.


Top
  Profile  
 
 Post subject: Re: Design Patterns
PostPosted: Tue Aug 10, 2010 8:42 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
DJSPIN80 wrote:
In OOP, inheritance/extension is a key component of sharing behavior between classes. However, with design patterns, it kind of shies away from inheritance proper (at least as a key fundamental of OOP). I could be wrong.

You're observation is right. Many design patterns are intended to eliminate the need for large inheritance hierarchies. A common mistake that many beginners and novice programmers make is to over-use inheritance, which should be used to create specialized versions of more general classes... animal <-- reptile <-- snake <-- boa. If you've read anything at all on AOP, you've almost surely seen something to the effect that OOP works along a single dimension (whereas AOP with it's cross-cutting concerns is able to work on multiple dimensions). Here we've specialized along from animal to boa along a single dimension.

The most common problem that occurs among students (and to a lessor extent among professionals) is the use of inheritance instead of composition. They'll create a hierarchy where motorcycle inherits from vehicle, engine, wheel, and gas-tank, which is a bad use of inheritance. A motorcycle "is" a type of vehicle, but it isn't a type of engine or wheel or gas-tank. It "has" these items, therefore composition is the correct choice.

And don't get me started on the number of times that I've heard someone say that "polymorphism and inheritance are the same thing". Arrr... =)


Top
  Profile  
 
 Post subject: Re: Design Patterns
PostPosted: Wed Aug 11, 2010 4:05 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
Gadget wrote:
You're observation is right. Many design patterns are intended to eliminate the need for large inheritance hierarchies. A common mistake that many beginners and novice programmers make is to over-use inheritance, which should be used to create specialized versions of more general classes... animal <-- reptile <-- snake <-- boa. If you've read anything at all on AOP, you've almost surely seen something to the effect that OOP works along a single dimension (whereas AOP with it's cross-cutting concerns is able to work on multiple dimensions). Here we've specialized along from animal to boa along a single dimension.


Well, it's been always my belief that inheritance is kind of like the comma; it should be used sparingly. My old app architect from my financial days said that "inheritance is a specific kind of something". Design patterns are interesting in that its focus is on dynamicness (if that's even a word) and allowing the code to morph during run-time.

My question to you is this: one of the principles I learned from design patterns is 'program to an interface and not an implementation.' I understand what that means but the term 'interface' is overloaded. Does this mean strictly to an interface like:

Code:
public class MyClass implements iMyInterface


Or is it loose pertaining to both interfaces and virtual classes? Just curious...


Top
  Profile  
 
 Post subject: Re: Design Patterns
PostPosted: Wed Aug 11, 2010 11:56 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Gadget wrote:
The most common problem that occurs among students (and to a lessor extent among professionals) is the use of inheritance instead of composition. They'll create a hierarchy where motorcycle inherits from vehicle, engine, wheel, and gas-tank, which is a bad use of inheritance. A motorcycle "is" a type of vehicle, but it isn't a type of engine or wheel or gas-tank. It "has" these items, therefore composition is the correct choice.

And don't get me started on the number of times that I've heard someone say that "polymorphism and inheritance are the same thing". Arrr... =)
I have not seen this professionally.... or even in school.


Top
  Profile  
 
 Post subject: Re: Design Patterns
PostPosted: Wed Aug 11, 2010 12:33 pm 
Java Junkie
Java Junkie
User avatar

Joined: Mon Jun 14, 2004 10:23 am
Posts: 24238
Location: Granite Heaven
CrashTECH wrote:
I have not seen this professionally.... or even in school.


I have seen it in both situations.

To be fair, the professional situations was code produced by a co-op student / intern for his project and by a new-hire fresh-grad who was tasked with creating a suite of automated testing tools.

In school, the person who (consistently) made this mistake was the same person who'd argue with the prof about the distinction between polymorphism and inheritance. Hilariously, he was in the 'Informatics' program the next year.


Top
  Profile  
 
 Post subject: Re: Design Patterns
PostPosted: Thu Aug 12, 2010 8:04 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
CrashTECH wrote:
I have not seen this professionally.... or even in school.


I've seen it in both as well.


Top
  Profile  
 
 Post subject: Re: Design Patterns
PostPosted: Thu Aug 12, 2010 2:29 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
CrashTECH wrote:
I have not seen this professionally.... or even in school.

It might be the case that the schools became proactive and minimized or eliminated the problem. I haven't had much involvement with undergrad programming / software engineering since 2004. If you were to ask some undergrads about the differences between and usages of composition, inheritance and polymorphism, I'd bet money that at least a quarter of them wouldn't know about one of the three.

Regarding professionals, don't forget that fizzbuzz included senior software engineers.


Top
  Profile  
 
 Post subject: Re: Design Patterns
PostPosted: Thu Aug 12, 2010 3:36 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
DJSPIN80 wrote:
Design patterns are interesting in that its focus is on dynamicness (if that's even a word) and allowing the code to morph during run-time.

Well, I don't know if I'd use the term "morph"; The code isn't actually changing. In most cases, there is simply another level of indirection that is used to determine who should/shouldn't receive a message. We'd probably be better off saying something like "decisions are delayed until runtime".

DJSPIN80 wrote:
I understand what that means but the term 'interface' is overloaded.

WTH were you thinking! You overloaded 'interface' -- really?! JK... I couldn't resist. =)

DJSPIN80 wrote:
Does this mean strictly to an interface like:
Code:
public class MyClass implements iMyInterface

Or is it loose pertaining to both interfaces and virtual classes? Just curious...


I'm not a huge fan of the religion known as software engineering, so my answer tends to always be "Do whatever produces the most elegant code -- period", which may or may not be such a good idea. I tend to do this quite a bit in Java: interface <-- abstract class <-- ... (if needed) <-- concrete class(es). However, I let the "most elegant code" rule dictate, so a less complicated program would probably not have the interface, while a more complicated or more general/larger program, might not only have the interface, but also have additional lower interfaces and abstract classes.

Quite a bit of OOP design (ie design patterns) assumes that you're using a language like C++, C# or Java where the message passing paradigm is much more "static" than in something like Smalltalk or LISP (and, to some degree, Obj-C). Of course, the people teaching this SE stuff try their best to be language agnostic and would argue that the design should be created without regard to the language, but let's be realistic, if your language doesn't support feature X, then you might not be able to implement pattern Y, or the implementation might be so confusing and ugly that you just say forget it (or you might not need to implement pattern Y if your language supports this pattern "invisibly").

I'm a bit rushed at the moment, but if we start getting into some patterns, I've always found the differences in implementation strategies to be somewhat interesting. Someone pick one or two of the patterns worth discussing*. We can move forward from there. *Except MVC, I'm soooo sick of that pattern!


Top
  Profile  
 
 Post subject: Re: Design Patterns
PostPosted: Fri Aug 13, 2010 4:12 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
Gadget wrote:
I'm not a huge fan of the religion known as software engineering, so my answer tends to always be "Do whatever produces the most elegant code -- period"


Neither am I but I adhere to some aspects of software engineering. I used to be under the assumption of "do whatever produces the most elegant code" but I've come across a lot of source files in my day and the term 'elegant code' varies different from developer. So I tend to say 'do whatever produces elegant code that's easy to understand and read.' I have this OCD-like compulsion to use known/shared vocabulary - anything to lessen the number of times a developer goes "huh?" is, to me, a success.

Quote:
Quite a bit of OOP design (ie design patterns) assumes that you're using a language like C++, C# or Java where the message passing paradigm is much more "static" than in something like Smalltalk or LISP (and, to some degree, Obj-C). Of course, the people teaching this SE stuff try their best to be language agnostic and would argue that the design should be created without regard to the language, but let's be realistic, if your language doesn't support feature X, then you might not be able to implement pattern Y, or the implementation might be so confusing and ugly that you just say forget it (or you might not need to implement pattern Y if your language supports this pattern "invisibly").


Honestly, DP assumes C++, C# and Java. Many of these patterns simply don't fit well into other languages. I think that DP has difficulty with procedural based languages like PHP or even Ruby. I think that some patterns don't fit well, like you said, because it doesn't support feature X. However, I'm sure that there are patterns that exist only in languages like Ruby or PHP.

Quote:
I'm a bit rushed at the moment, but if we start getting into some patterns, I've always found the differences in implementation strategies to be somewhat interesting. Someone pick one or two of the patterns worth discussing*.


I just learned my first pattern, the Strategy Pattern. Could we discuss where and how we could implement this pattern? Also, another pattern that confuses me is the Decorator Pattern. I kind of understand it, but I never understood its implementation. Maybe that's my problem; I think about implementation over design too much. Anyways, I don't care, it's worth discussing. :)


Top
  Profile  
 
 Post subject: Re: Design Patterns
PostPosted: Fri Aug 13, 2010 4:19 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Elegant isn't always maintainable or very readable. In the professional world, making your code READABLE is more important (IMO). Especially because you won't always been the one supporting that code base. We have a project from a previous developer that went crazy with classes. We didn't have the situation above, but for example if we were dealing with an application catalog/management system.... there was an Application Class, Installed, PendingInstall, ToUpdate, etc etc.

I would have just put a status field on the Application class, but that is just me (and I wasn't saying that the above solution was elegant by any means :) )


Top
  Profile  
 
 Post subject: Re: Design Patterns
PostPosted: Sat Aug 14, 2010 11:19 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
CrashTECH wrote:
Elegant isn't always maintainable or very readable. In the professional world, making your code READABLE is more important (IMO).

Hmm... elegant generally implies both maintainable and readable. Can you give an example of code that is elegant, but not maintainable or readable?

CrashTECH wrote:
I would have just put a status field on the Application class, but that is just me (and I wasn't saying that the above solution was elegant by any means :) )

I was going to say!


Top
  Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

© 2014 Future US, Inc. All rights reserved.