C++ Design Principles for Ruby - Prefer Abstract Interfaces.

C++ Design Principles for Ruby - Prefer Abstract Interfaces.

Post by John Carte » Wed, 03 Aug 2005 08:35:19


refer to inherit from abstract classes that have pure virtual functions
with no implementation and no state.

Use the Dependency Inversion Principle: High Level modules should not
depend upon low level modules, both should depend on abstractions.
Abstractions should not depend on details, rather details should depend on
abstractions.

Rubyizing that....

Ruby does not have a notion of "pure virtual" function like C++. Or the
notion of an "interface" like Java.

Partly it doesn't matter since Ruby duck-types. You don't need to inherit
from a common abstract class. But still I like to collect the signature of
the "duck" somewhere so sometimes I use this idiom...

class AbstractFoo
# Description...
def signature_1( a, b, c)
raise "Pure virtual"
end

# Description...
def signature_2( d, e)
raise "Pure virtual"
end
end

class ConcreteA < AbstractFoo
def signature_1( a, b, c)
end

def signature_2( d, e)
end
end


I also have my nifty "quacks_like" assertion..


class BigHairyThing
def does_lots( thing)
thing.quacks_like( :duck) # Assert


thing.duck
end
end

====================================================

# Abstract base class for all the type check exceptions
class TypeCheckException < Exception
end

# This exception is thrown in event of a method being invoked with an
# object of the wrong duck type.
class DuckTypingException < TypeCheckException
end

# This exception is thrown in event of a method being invoked with a
# parameter of of the wrong static type.
class StaticTypeException < TypeCheckException
end

# This exception is thrown in event of a method being invoked with a
# parameter of of the wrong polymorphic type.
class PolymorphicTypeException < TypeCheckException
end


class Object

# Raise a DuckTypingException unless the object responds to all symbol.
def quacks_like( *symbols)
symbols.each do |symbol|
raise DuckTypingException, "Duck typing error, expected this object
to respond to :#{symbol}, but found class #{self.class}" unless
respond_to? symbol
end
end

def static_type_check( klass)
raise StaticTypeException, "Static type check error, expected object
to be exactly class '#{klass}', found '#{self.class}'" unless
self.class == klass
end

def polymorphic_type_check( klass)
raise PolymorphicTypeException, "Polymorphic type check error,
expected object to be a kind of '#{klass}', found '#{self.class}'" unless
self.kind_of? klass
end


end


if $0 == __FILE__ then
require 'test/unit'

class TC_Utilities < Test::Unit::TestCase

def test_utilities
assert_raise( DuckTypingException) { nil.quacks_like( :call)}
assert_raise( DuckTypingException) { 1.quacks_like( :+, :call)}
1.quacks_like( :+, :-, :*)

assert_raise( StaticTypeException) { nil.static_type_check( String)}

assert_raise( PolymorphicTypeException)
{"foo".polymorphic_type_check( Array)}

begin
2.static_type_check( String)
rescue TypeCheckException => details
puts details
end
begin
2.polymorphic_type_check( String)
rescue TypeCheckException => details
puts details
end
end
end

end


John Carter Phone : (64)(3) 358 6639
Ta
 
 
 

1. Exceptional C++ Book Item 32 Interface Principle

2. How to borrow interface design/resources from eMbedded Visual C++ to Visual C++ and vice versa

I am developing a GUI with eMbedded Visual C++ and Visual Studio.

I loaded a bitmap of an iPAQ emulator to a dialog, then expanded the bitmap
to fit all space of the dialog. Since the iPAQ emulator is kind of like a
ellipse, and the dialog itself is a rectangle, so when the dialog is
displayed, both the iPAQ emulator and the blank background close to the
emulator become visible. I only want to show the exact elliptic contour of
the emulator, not a rectangle, any ideas? I would like to develop a desktop
application first then convert it to a PPC application.

Thanks in advance.

John

3. Interface rather than abstract class in Abstract Factory?

4. interfaces / abstract classes / design problem_Solved

5. f2003 - abstract types and abstract interfaces

6. Design question - interface, abstract class, or ???

7. interfaces / abstract classes / design problem

8. Design question - Abstract, base, interfaces, ack!

9. Q re Bridge Design Pattern - Abstract Classes vs Interfaces

10. Design principles in C++ (especially converning templates and library development)?

11. Language Design Principles, was C++ intermediate representation.

12. Liskov Substitution Principle and Abstract Factories

13. Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]

14. Minimalist design principles in systems design