why i use interface:
- because I not sure the future customer will introduce more products
into the system, which I should be ready to extend the system?

but, is it valid? is that a good OO design? many thanks!

why i use interface:
- because I not sure the future customer will introduce more products
into the system, which I should be ready to extend the system?

but, is it valid? is that a good OO design? many thanks!

Never write speculative code. Instead, write lots of unit tests on your
existing behavior.

When the future actually arrives (in the current climate "IF" it arrives!),
you will be ready with minimal code and lots of tests, so you can easily
introduce an interface, if your customer indeed introduces more products.

However, if they ask for a different feature, then your interface WON'T GET
IN THE WAY. Keeping your codebase as light as possible, while it grows in
features, is mission-critical.

And if you can find a real reason with the _current_ feature requirements to
introduce the interface, go for it! It's just that some of us are starting
to realize that unit tests are much more important than proactive
designing...

my draft idea..

[InterfaceProduct]
-int Sample
+SampleMethod

[Product]
-Price
+GetPrice

[Seat]
-SeatNo
+GetSeatNo

[Room]
-RoomNo
+GetRoomNo

[Order]
- Array<Product

and i was thinking..

why i use inheritance:
- because I have an [Order] class which need to include [Product] as
part of the field/property inside, which could be any of the product
type.

why i use interface:
- because I not sure the future customer will introduce more products
into the system, which I should be ready to extend the system?

Guess my concept of OO isn't strong enough. No doubt I still trap in
the era of structural/procedural programming + RDBMS (vb, php, mysql
etc) and treats class design like rdbms table design.

I've learned java (plus some OO with PHP) before and know the benefits
of OO. And that's why I want to get rid of the old programming style
and head towards OO (with C# now).

"H. S. Lahman" <h.lah... at (no spam) verizon.net> wrote:

Responding to s.i.g...

Guess my concept of OO isn't strong enough. No doubt I still trap in
the era of structural/procedural programming + RDBMS (vb, php, mysql
etc) and treats class design like rdbms table design.

Yes. To do OO development properly you need to forget everything you
ever learned about P/R.

It's not all that bad. OO is not revolutionary, it's evolutionary.
Anybody who has a solid grasp of the modular programming paradigm will
feel quite at home in an OO context. They won't have very much to learn
at all.

Responding to s.i.g...

Guess my concept of OO isn't strong enough. No doubt I still trap in
the era of structural/procedural programming + RDBMS (vb, php, mysql
etc) and treats class design like rdbms table design.

Yes. To do OO development properly you need to forget everything you
ever learned about P/R.

I've learned java (plus some OO with PHP) before and know the benefits
of OO. And that's why I want to get rid of the old programming style
and head towards OO (with C# now).

Alas, learning the OO paradigm by coding in an OOPL is a very poor way
to learn the paradigm.

The OOPLs are still 3GLS and they make a lot of
compromises with the hardware computational models.

My advice would be to take a break and read a couple of books on OOA/D.
The "Books" category of by blog provides some advice on finding a good
OOA/d book.

On May 11, 7:54 pm, "Daniel T." <danie... at (no spam) earthlink.net> wrote:
"H. S. Lahman" <h.lah... at (no spam) verizon.net> wrote:

Responding to s.i.g...

Guess my concept of OO isn't strong enough. No doubt I still trap in
the era of structural/procedural programming + RDBMS (vb, php, mysql
etc) and treats class design like rdbms table design.

Yes. To do OO development properly you need to forget everything you
ever learned about P/R.

It's not all that bad. OO is not revolutionary, it's evolutionary.
Anybody who has a solid grasp of the modular programming paradigm will
feel quite at home in an OO context. They won't have very much to learn
at all.

I think that good class models have a structure similar to that seen
in well-structured relational databases, owing to the normal forms.
Schlaer and Mellor were the ones who really advocated this view point.

So a lot of what you know about relational model, i.e. how to design
tables, can apply to OO. However, OO is a huge break from procedural
programming.

Guess my concept of OO isn't strong enough. No doubt I still trap in
the era of structural/procedural programming + RDBMS (vb, php, mysql
etc) and treats class design like rdbms table design.
Yes. To do OO development properly you need to forget everything you
ever learned about P/R.

It's not all that bad. OO is not revolutionary, it's evolutionary.
Anybody who has a solid grasp of the modular programming paradigm will
feel quite at home in an OO context. They won't have very much to learn
at all.

I've learned java (plus some OO with PHP) before and know the benefits
of OO. And that's why I want to get rid of the old programming style
and head towards OO (with C# now).
Alas, learning the OO paradigm by coding in an OOPL is a very poor way
to learn the paradigm.

I would qualify that somewhat. Learning the OO paradigm using a single
3GL language is harder than learning it if you understand multiple
languages.

The OOPLs are still 3GLS and they make a lot of
compromises with the hardware computational models.

Not completely true. Some languages refuse to make those compromises,
they have a harder time in the marketplace because of it though (I'm
thinking primarily of Smalltalk here.)

Pushing common data up into common base classes in the name of
"normalization" is one of the biggest problems I see in beginner's OO
practice. You can get away with it in a dynamic typed language, because
the inheritance relationship doesn't create as tight a coupling. but...

When dealing with a static typed language, things are a little more
involved, because inheritance serves double duty. Whenever you have one
construct that represents more than one abstract concept things get
problematic. (That problem started this thread.)

So a lot of what you know about relational model, i.e. how to design
tables, can apply to OO. However, OO is a huge break from procedural
programming.

I don't think so. A class is full of procedural code, all OO does is
wrap that procedural code in a higher level of abstraction so it is
easier to deal with.

All the OO paradigm does (imho) is make modularization easier and
interfaces pervasive.

"H. S. Lahman" <h.lahman at (no spam) verizon.net> wrote:

Yes. To do OO development properly you need to forget everything you
ever learned about P/R.

It's not all that bad. OO is not revolutionary, it's evolutionary.
Anybody who has a solid grasp of the modular programming paradigm will
feel quite at home in an OO context. They won't have very much to learn
at all.

Learning the OO paradigm using a single
3GL language is harder than learning it if you understand multiple
languages.

Responding to Daniel T....

Pushing common data up into common base classes in the name of
"normalization" is one of the biggest problems I see in beginner's OO
practice. You can get away with it in a dynamic typed language, because
the inheritance relationship doesn't create as tight a coupling. but...

When dealing with a static typed language, things are a little more
involved, because inheritance serves double duty. Whenever you have one
construct that represents more than one abstract concept things get
problematic. (That problem started this thread.)

I see the problem somewhat differently and from that perspective I don't
think it has much to do with statically vs. dynamically bound OOPLs. For
example, we've both seen a lot of LSP debates online that were based on
models like:

[Rectangle]
+ majorSideLength
+ minorSideLength
+ behaviorX
A
|
+-------------...
|
[Square]
+ sideLength

The debaters will go on an on about arcane implementations of behaviorX
that break and how to specify that behavior to avoid LSP issues. Yet
they never seem notice that the real problem is a basic generalization
error in defining the side length knowledge attributes. IOW, they don't
seem to think that LSP applies to knowledge as well as behavior.

Because of the basic set focus of OO generalization, any member of the
[Rectangle] set *must* have a majorSideLength and a minorSideLength.
That instantly creates at least two 3NF violations for any member of the
[Square] subset. It also violates the basic is-a notion of OO
generalization because the knowledge semantics is fundamentally
different so that a Square is something quite different than a Rectangle
and can't be Rectangle.

[Note that the problem doesn't get any better if one leaves off
Square::sideLength. If both majorSideLength and minorSideLength are set
to the same value, one has a 3NF violation because one value is
dependent on the other rather then the Square identity. If one leaves
one value uninitialized, one has a 1NF violation because the data domain
is not simple.]

Of course if one did the generalization correctly, one would end up with
something like:

[RegularPolygon]
A
|
+-----------+-----------+
| |
[4Sided] [MultiSided]
A A
| |
+-----+----------+---... ...
| |
[Square] [Rectangle]
+ sideLength + majorSideLength
+ minorSideLength

Now the knowledge definitions have consistent subset scope. More to the
point, one can probably define behaviorX at some level so that LSP and
NF are not violated without a whole lot of difficulty.

Bottom line: I don't see a problem with superclasses having knowledge
attributes -- so long as one ensures that those attributes are valid and
semantically equivalent for every descendant subclass. But I see that
stricture is an OOA/D issue, not an OOPL issue.

So a lot of what you know about relational model, i.e. how to design
tables, can apply to OO. However, OO is a huge break from procedural
programming.

I don't think so. A class is full of procedural code, all OO does is
wrap that procedural code in a higher level of abstraction so it is
easier to deal with.

Wow. I'm really surprised that you feel that way.

All the OO paradigm does (imho) is make modularization easier and
interfaces pervasive.

There is no doubt that modularization is easier. But I think that is
just a convenient byproduct of decoupling via interfaces. In turn,
interfaces provide a mechanism for decoupling, so they are ubiquitous.

But I think the primary goal of the OO paradigm is to provide decoupling
among software elements. That's what encapsulation and implementation
hiding are all about. I also think that the separation of message and
method in OOA/D provides a fundamental shift in construction paradigms
from the imperatives (Do This) of procedural development and the
announcements (I'm Done) of OO development. That changes the whole
mindset of program construction from hierarchical, functional
decomposition flow of control to peer-to-peer, DbC-based flow of control.

Procedural development strongly encouraged implementation dependencies
among behaviors so that the legendary Spaghetti Code was commonplace.
(One could write modular, decoupled programs in procedural languages but
it was damned difficult and required a good deal of skill and
experience.) OTOH, the OO paradigm strongly discourages any sort of
dependencies among methods so that even entry level developers can
create fairly maintainable programs.

Of course if one did the generalization correctly, one would end up with
something like:

[RegularPolygon]
A
|
+-----------+-----------+
| |
[4Sided] [MultiSided]
A A
| |
+-----+----------+---... ...
| |
[Square] [Rectangle]
+ sideLength + majorSideLength
+ minorSideLength

Now the knowledge definitions have consistent subset scope. More to the
point, one can probably define behaviorX at some level so that LSP and
NF are not violated without a whole lot of difficulty.

Bottom line: I don't see a problem with superclasses having knowledge
attributes -- so long as one ensures that those attributes are valid and
semantically equivalent for every descendant subclass. But I see that
stricture is an OOA/D issue, not an OOPL issue.

Also note however that you are normalizing based on interface
contracts, not based on data. If the data happens to be normalized
too, great but that isn't the goal of the hierarchy.

So a lot of what you know about relational model, i.e. how to design
tables, can apply to OO. However, OO is a huge break from procedural
programming.
I don't think so. A class is full of procedural code, all OO does is
wrap that procedural code in a higher level of abstraction so it is
easier to deal with.
Wow. I'm really surprised that you feel that way.

What? Even you use an action language to implement methods. That
action language must have loops and if statements. Private methods in
a class are simply a syntactical variant of procedures, especially if
they are not meant to be over-ridden.

All the OO paradigm does (imho) is make modularization easier and
interfaces pervasive.
There is no doubt that modularization is easier. But I think that is
just a convenient byproduct of decoupling via interfaces. In turn,
interfaces provide a mechanism for decoupling, so they are ubiquitous.

But I think the primary goal of the OO paradigm is to provide decoupling
among software elements. That's what encapsulation and implementation
hiding are all about. I also think that the separation of message and
method in OOA/D provides a fundamental shift in construction paradigms
from the imperatives (Do This) of procedural development and the
announcements (I'm Done) of OO development. That changes the whole
mindset of program construction from hierarchical, functional
decomposition flow of control to peer-to-peer, DbC-based flow of control.

I agree with the above, except for that last sentence. Well written
modular code has the same mindset IMHO.

Procedural development strongly encouraged implementation dependencies
among behaviors so that the legendary Spaghetti Code was commonplace.
(One could write modular, decoupled programs in procedural languages but
it was damned difficult and required a good deal of skill and
experience.) OTOH, the OO paradigm strongly discourages any sort of
dependencies among methods so that even entry level developers can
create fairly maintainable programs.

I fully agree with the above. To paraphrase Riel, OO added a syntax
that made it easy for even average programmers to conform to modular
programming's best practices. I wouldn't call making it easier for
average people to do the same thing that experienced people do any
sort of "revolution" though.

The Big Three characteristics of 3GLs are: procedural block structuring,
stack-based scope, and procedural message passing. All the OOPLs,
including Smalltalk, still depend on those things. (Though some, like
Smalltalk, do a better job of hiding it by employing less obvious syntax.)

But the real problem with the 3GLs is physical coupling due to the use
of type systems to deal with the Big Three. That introduces the need for
refactoring _just to make the 3GL code more maintainable_ (as opposed to
solving the customer's problem). That sort of refactoring after the
logic is working correctly is totally unnecessary at the 4GL level of
OOA/D. Worse, at the OOP level it can lead to architectural drift in the
long term.

Every OOPL employs a sophisticated type system. So in that sense the
OOPLs are even worse than the procedural languages; the type system
itself is a major compromise with the hardware computational models.