Matt Weisfeld

author
+ Follow
since May 01, 2013
Merit badge: grant badges
Biography
Matt Weisfeld is a college professor, software developer, and author based in Cleveland, Ohio. Prior to becoming a  full time professor, Matt spent 20 years in the information technology industry as a software developer, entrepreneur, corporate trainer and adjunct professor. Matt holds an MS in computer science and an MBA. Besides the first three editions of The Object-Oriented Thought Process, Matt has authored two other software development books and published many articles in magazines and journals, such as developer.com, Dr. Dobb’s Journal, The C/C++ Users Journal, Software Development Magazine, Java Report and the international journal Project Management.
Cows and Likes
Cows
Total received
5
In last 30 days
0
Total given
0
Likes
Total received
3
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Matt Weisfeld

A lot boils down to cost of the systems and how much making more detailed designs is really worth it to you. Remember also that the more detailed the design, the more complicated it can be to implement and maintain. As for the examples you bring up regarding the birds and the dogs, I am not sure that this is exactly what you are looking for, but you can use a hierarchy of birds. When you ask people to describe the most common behavior of birds almost everyone would say 'flight". However, not all birds fly. So you would have to decide if you want to create a Bird class that doesn't include a "flight" method. Perhaps you would need 2 classes, FlyingBirds and FlightLessBirds that inherits from the Bird class. There really is no right or wrong way to handle the design - it just makes for interesting discussions. Not all dogs can bark either so you can create a Dog class without the bark behavior and then use inheritance and create a BarkingDog and a BarklessDog. This approach might model the system correctly, but it is more complex. The one thing that I would not do, for example, is create a Bird class, include a Fly method, and create a no-op for some birds (basically have the fly method that won't fly but generates an error message etc). I like to use the example of a Penguin who sees that there is a fly method and then leaps off the cliff - only to receive an error message that indicates that Penguins can't fly. By that time it is too late - basically the system is not realistic.
This is an interesting topic. Your question may fit well with an earlier thread on separating behaviors in classes. For example, you can use a hierarchy of birds. When you ask people to describe the most common behavior of birds almost everyone would say 'flight". However, not all birds fly. So you would have to decide if you want to create a Bird class that doesn't include a "flight" method. Perhaps you would need 2 classes, FlyingBirds and FlightLessBirds that inherits from the Bird class. There really is no right or wrong way to handle the design - it just makes for interesting discussions. Not all dogs can bark either. Aspects may allow a different approach to thye design. Is this what you were thinking?
Yes, I came from structured programming as well - even started in Cobol and Assembler, then C.

I took a Smalltalk class in the mid-90's (I think) and the instructor said that about 20% of structured programmers (even the really good ones) would never really get (or perhaps, embrace) object-oriented development. I always wondered if this was actually true over the long haul.
I strongly believe that there is no single, right way to approach most anything - things are always evolving fast in this business. So I like to take what I consider the 'best practices' of many approaches and try to come up with a process that makes sense. I know that this is really difficult and everyone's 'best practices' may be different but when things change so fast, I don't see an alternative.
Design patters are obviously important, but as with anything, you don't want to grab a powerful tool before you understand what the job at hand is. My approach to teaching the OO concepts is to concentrate on the basic, fundamental concepts and try to reinforce those using various tools like code in Java, C# and Objective-C, etc. Then I use very basic examples of specific technologies like XML, Design Patterns, etc.

Personally, I would focus on the basic concepts first: such as encapsulation, polymorphism, interfaces, composition and inheritance and get comfortable with those. You can then study some specific topics like design patterns to see how the concepts are applied.

As far as UML goes, in my writings and when I teach programming, I like to use UML class diagrams as a graphical way to assist in the learning process. I find that UML class diagrams are really good for demonstrating how to model systems and show relationships between classes.
The really interesting thing for me when I started training/teaching Java and OO concepts in the late '90s was that I realized that many people were under the impression that structured and object-oriented programming were mutually exclusive. As I have discussed, I don't agree with that. I contend that structured programming techniques are actually encapsulated with object-oriented design. Thus, they work together. When I am teaching college students, some like to get right into writing code and then honing the concepts later. Others like learning the concepts first. It is obvious to me that there is really no absolutely correct answer - but I keep looking!
My approach is to use several different types of tools to try and help people understand object concepts. For some people, the light bulb may go on by writing small bits of code and seeing what works and what doesn't. For others, something more graphical in nature might do the trick. The bottom line for me as I have been training/teaching is to use several techniques to try and explain the concepts in the hopes that one technique or a combination of the techniques will do the job.
Hi Chan,

I agree. Introducing OO concepts early on is essential - specifically what classes and objects are, etc.

As I do Java training I realize that many people are under the impression that structured and object-oriented programming were mutually exclusive. I don't agree with that. I contend that structured programming techniques are actually encapsulated with object-oriented design. Thus, they work together. I tend to introduce both structured and OO concepts early.

Thanks,

Matt
OK - have you read many books or Internet articles on design patterns. This may be a good place to start if you are interested in how to implement object-oriented designs - at least from the practical standpoint. There are also some good books on the topic. This one was written in 1998, but it has always been one of my favorites.

http://www.amazon.com/MWSS-Object-Oriented-Design-Mitchell-Signature/dp/1571691340
Hey everyone,

I am really enjoying participating in this forum and I appreciate all of the questions.

One topic that I would be really interested in getting some feedback on is this: when teaching Java programming to new students, is it better to start with the structured constructs like loops, conditions, etc, or the object concepts like classes, objects, methods, etc.

This has been of great interested to me since I transitioned from 20 years of professional programming in C, C++, Java , etc to teaching at the college level.

Thanks,

Matt
Hi Prasanna,

Each organization is going to do thing differently, but the main thing would be to concentrate on the interfaces with the systems that class needs to interface with. The bottom line is getting the job done and everyone is going to have a different approach to doing that. For example, if you are asked to create a Zoo class, that may really be the wrong way to approach the interview. The primary question would be what does the required application need to do and what systems are already in place to do it. The new class may simply be a wrapper to encapsulate functionality that already exists. In any case, you would first need to do the analysis and come up the requirements.
I guess the short answer is that a class won't stand alone, it will be part of an object model that is meant to implement an application. So asking you to describe a single Zoo class may be a loaded question.

Does that help?

Matt
Again, I do like using the UML class diagrams to represent the models. Basically, I can model the attributes (public/private) and methods in a small, concise manner. I can also represent inheritance and composition (aggregations and associations) relationships in a straightforward manner. Since there are only several concepts involved: attributes, methods, inheritance and composition, I find the class diagrams to be pretty useful.
Hi,

There is no chapter in the book on functional programming or closures, etc. However, the primary premise of the book is that object-oriented programming is not a paradigm unto itself and encapsulates various other development paradigms - which is discussed throughout the book.

Matt
One of the really interesting projects I have been following for years now is the Alice project based at Carnegie Melon. I have made many presentations to high school and college kids about this. It is a graphical approach to learning to program - primarily using objects. Anyway, you may be interested in the approach: http://www.alice.org/index.php.

One thing when I try to teach intro to programming is that I want to get the students to get really interested - really quickly. If I start with the design stuff at the beginning I seem to lose many. Thus, over the years, I tend to start off with some structured code doing some loops, conditions, etc and then move into the objects in about week 3. Perhaps they still need to understand what a variable is first.
I am not sure that this is exactly what you are looking for, but you can use a hierarchy of birds. When you ask people to describe the most common behavior of birds almost everyone would say 'flight". However, not all birds fly. So you would have to decide if you want to create a Bird class that doesn't include a "flight" method. Perhaps you would need 2 classes, FlyingBirds and FlightLessBirds that inherits from the Bird class. There really is no right or wrong way to handle the design - it just makes for interesting discussions. Not all dogs can bark either.