ООП: что главнее, матрица или вектор

Цитата MyNameIsIgor @ 20.08.14, 08:40

Цитата D_KEY @ 20.08.14, 08:33

Вот, например, тип квадрата теоретически мог бы задаваться предикатом над прямоугольником(а тот в свою очередь предикатом над многоугольником и т.д.)

Как этот предикат соотносится с системой типов языка?

Вроде scheme умеет создавать типы по предикатам. Тут нужен korvin

Добавлено 20.08.14, 08:48

Цитата MyNameIsIgor @ 20.08.14, 08:40

ибо нам по каким-то причинам не захотелось выразить очевидное отношение.

Нам этого не захотелось делать, потому что мы не можем нормально соблюдать инварианты базы и/или не усилить предусловия и/или не ослабить постусловия базовых методов. Проще говоря, у нас разный набор операций, т.е. в нашей модели квадраты не являются видами прямоугольников...

Цитата D_KEY @ 20.08.14, 08:43

Нам этого не захотелось делать, потому что мы не можем нормально соблюдать инварианты базы и/или не усилить предусловия и/или не ослабить постусловия базовых методов

На самом деле, не вижу подобных проблем, если мы можем переопределить все необходимые методы.

Цитата D_KEY @ 20.08.14, 08:43

т.е. в нашей модели квадраты не являются видами прямоугольников...

... но по твоим же словам являются таковыми в предметной области, и, конечно, ООП не виновато, что наша система не отражает предметную область Хорошо, я понял правила.

Цитата MyNameIsIgor @ 20.08.14, 09:14

Цитата D_KEY @ 20.08.14, 08:43

Нам этого не захотелось делать, потому что мы не можем нормально соблюдать инварианты базы и/или не усилить предусловия и/или не ослабить постусловия базовых методов

На самом деле, не вижу подобных проблем, если мы можем переопределить все необходимые методы.

Это делает не применимым наследование согласно принципу подстановки. В нашем примере все портят возможные методы изменения одной из сторон прямоугольника.

Цитата

Цитата D_KEY @ 20.08.14, 08:43

т.е. в нашей модели квадраты не являются видами прямоугольников...

... но по твоим же словам являются таковыми в предметной области

Но для нашей модели предметной области это не существенно. Если существенно, нужно было так и проектировать.

Цитата

и, конечно, ООП не виновато, что наша система не отражает предметную область Хорошо, я понял правила.

Наша система должна отражать предметную область только в той степени, в которой нам это необходимо для успешного моделирования задачи(и потенциального ее расширения и уточнения). Нет?

Цитата D_KEY @ 20.08.14, 08:43

Вроде scheme умеет создавать типы по предикатам.

Racket, если точнее. Впрочем как и любой динамически-типизированный язык, по понятным причинам. Так что это сложно назвать типами в привычном смысле этого слова.

#lang racket
 
(define/contract (natural? x) predicate/c
  (and (integer? x)
       (positive? x)))
 
(define/contract (natural+ x y) (natural? natural? . -> . natural?)
  (+ x y))
 
(displayln (natural+ 1 2))
(displayln (natural+ 1.2 3))

3
. . ..\..\Program Files\Racket\collects\racket\contract\private\blame.rkt:135:0: natural+: contract violation
  expected: natural?
  given: 1.2
  in: the 1st argument of
      (-> natural? natural? natural?)
  contract from: (function natural+)
  blaming: anonymous-module
  at: unsaved-editor2793:7.18
>

Другое дело, что в Racket можно создавать полноценно новые типы на основе существующих, что вряд ли есть хоть в каком-то динамически-типизированном языке, да и в статических не часто встречается.

Например:

complex.rkt:

#lang racket
 
(provide/contract
 #:exists complex
 (make-complex (-> number? number? complex))
 (real-part (-> complex number?))
 (imag-part (-> complex number?)))
 
(define (make-complex real imag)
  (cons real imag))
 
(define (real-part c)
  (car c))
 
(define (imag-part c)
  (cdr c))

test.rkt:

#lang racket
 
(require "complex.rkt")
  
(define c (make-complex 1 2))
(printf "~a+~ai\n" (real-part c) (imag-part c))
(printf "~a+~ai\n" (car c) (cdr c))

1+2i
. car: contract violation
  expected: pair?
  given: #<complex/∃>
>

Добавлено 20.08.14, 09:31

Цитата D_KEY @ 20.08.14, 09:29

Наша система должна отражать предметную область только в той степени, в которой нам это необходимо для успешного моделирования задачи(и потенциального ее расширения и уточнения). Нет?

А как же повторное использование? Как же библиотеки? Т.е. мы не можем (в ряде случаев) просто написать библиотеку классов, которая бы везде подходила?

Цитата korvin @ 20.08.14, 09:29

А как же повторное использование?

Ну так используй повторно, если оно тебе подходит. Проблема в чем?

Цитата

Т.е. мы не можем (в ряде случаев) просто написать библиотеку классов, которая бы везде подходила?

В ряде случаев не можем. И не только "классов". Ты где-то видел другое?

Квадратное равнение не является частным случаем кубического, поскольку в определении кубического уравнения особо оговорено, что коэфииент при x³ не равен нулю. Так же как в квадратном оговаривается, что не равен нулю коэффициент при x².