ฉันรู้ว่าแนวคิดของค่าคงที่มีอยู่ในกระบวนทัศน์การเขียนโปรแกรมหลายรายการ ตัวอย่างเช่นค่าคงที่ลูปมีความเกี่ยวข้องใน OO การเขียนโปรแกรมเชิงฟังก์ชันและโพรซีเดอร์

อย่างไรก็ตามชนิดหนึ่งที่มีประโยชน์มากที่พบใน OOP คือค่าคงที่ของข้อมูลประเภทใดประเภทหนึ่ง นี่คือสิ่งที่ฉันเรียกว่า "ค่าคงที่ประเภทตาม" ในชื่อ ตัวอย่างเช่นFractionประเภทอาจมีnumeratorและdenominatorด้วยค่าคงที่ gcd ของพวกเขาเสมอ 1 (เช่นเศษส่วนอยู่ในรูปแบบลดลง) ฉันสามารถรับประกันได้เพียงแค่มีการห่อหุ้มบางประเภทไม่ให้ข้อมูลถูกตั้งค่าอย่างอิสระ ในทางกลับกันฉันไม่ต้องตรวจสอบว่ามันลดลงหรือไม่ดังนั้นฉันจึงสามารถลดความซับซ้อนของอัลกอริทึมเช่นการตรวจสอบความเท่าเทียมกันได้

ในทางตรงกันข้ามถ้าฉันเพียงแค่ประกาศFractionประเภทโดยไม่ให้การรับประกันนี้ผ่านการห่อหุ้มฉันไม่สามารถเขียนฟังก์ชันใด ๆ ในประเภทนี้ได้อย่างปลอดภัยซึ่งคิดว่าเศษส่วนจะลดลงเพราะในอนาคตคนอื่นอาจเข้ามาและเพิ่มวิธี จากการได้รับเศษส่วนที่ไม่ลดลง

โดยทั่วไปการขาดค่าคงที่ประเภทนี้อาจนำไปสู่:

• อัลกอริทึมที่ซับซ้อนมากขึ้นเนื่องจากต้องมีการตรวจสอบ / รับประกันล่วงหน้าในหลาย ๆ สถานที่
• การละเมิด DRY เนื่องจากเงื่อนไขล่วงหน้าซ้ำ ๆ เหล่านี้แสดงถึงความรู้พื้นฐานที่เหมือนกัน (ที่ค่าคงที่ควรเป็นจริง)
• มีการบังคับใช้เงื่อนไขล่วงหน้าผ่านความล้มเหลวรันไทม์มากกว่าการรวบรวมเวลารับประกัน

ดังนั้นคำถามของฉันคือสิ่งที่การเขียนโปรแกรมการทำงานตอบสนองค่าคงที่ประเภทนี้ มีวิธีการทำงานที่เป็นไปตามสำนึกของการบรรลุสิ่งเดียวกันมากขึ้นหรือน้อยลง? หรือมีลักษณะบางอย่างของการเขียนโปรแกรมฟังก์ชั่นซึ่งทำให้ประโยชน์ที่เกี่ยวข้องน้อยลง?

บางภาษาทำงานเช่น OCaml ได้ในตัวกลไกที่จะใช้ชนิดข้อมูลนามธรรมดังนั้นการบังคับใช้บางส่วนคงที่ ภาษาที่ไม่มีกลไกดังกล่าวขึ้นอยู่กับผู้ใช้“ ไม่ได้ดูใต้พรม” เพื่อบังคับใช้ค่าคงที่

ชนิดข้อมูลนามธรรมใน OCaml

ใน OCaml โมดูลจะใช้เพื่อจัดโครงสร้างโปรแกรม โมดูลมีการนำไปใช้และลายเซ็นซึ่งเป็นชนิดของการสรุปค่าและประเภทที่กำหนดไว้ในโมดูลในขณะที่โมดูลเดิมให้นิยามที่แท้จริง สิ่งนี้สามารถเปรียบเทียบได้อย่างหลวม ๆ กับ diptych ที่.c/.hคุ้นเคยกับโปรแกรมเมอร์ C

ตัวอย่างเช่นเราสามารถใช้Fractionโมดูลดังนี้:

# module Fraction = struct
  type t = Fraction of int * int
  let rec gcd a b =
    match a mod b with
    | 0 -> b
    | r -> gcd b r

  let make a b =
   if b = 0 then
     invalid_arg "Fraction.make"
   else let d = gcd (abs a) (abs b) in
     Fraction(a/d, b/d)

  let to_string (Fraction(a,b)) =
    Printf.sprintf "Fraction(%d,%d)" a b

  let add (Fraction(a1,b1)) (Fraction(a2,b2)) =
    make (a1*b2 + a2*b1) (b1*b2)

  let mult (Fraction(a1,b1)) (Fraction(a2,b2)) =
    make (a1*a2) (b1*b2)
end;;

module Fraction :
  sig
    type t = Fraction of int * int
    val gcd : int -> int -> int
    val make : int -> int -> t
    val to_string : t -> string
    val add : t -> t -> t
    val mult : t -> t -> t
  end

คำจำกัดความนี้สามารถใช้ได้ดังนี้:

# Fraction.add (Fraction.make 8 6) (Fraction.make 14 21);;
- : Fraction.t = Fraction.Fraction (2, 1)

ทุกคนสามารถสร้างคุณค่าของเศษส่วนประเภทได้โดยตรงโดยไม่ต้องผ่านเครือข่ายความปลอดภัยภายในFraction.make:

# Fraction.Fraction(0,0);;
- : Fraction.t = Fraction.Fraction (0, 0)

เพื่อป้องกันสิ่งนี้คุณสามารถซ่อนนิยามที่เป็นรูปธรรมของประเภทFraction.tดังนี้:

# module AbstractFraction : sig
  type t
  val make : int -> int -> t
  val to_string : t -> string
  val add : t -> t -> t
  val mult : t -> t -> t
end = Fraction;;

module AbstractFraction :
sig
  type t
  val make : int -> int -> t
  val to_string : t -> string
  val add : t -> t -> t
  val mult : t -> t -> t
end

วิธีเดียวที่จะสร้างAbstractFraction.tคือการใช้AbstractFraction.makeฟังก์ชั่น

ชนิดข้อมูลนามธรรมใน Scheme

ภาษา Scheme ไม่มีกลไกข้อมูลนามธรรมชนิดเดียวกับที่ OCaml ทำ มันขึ้นอยู่กับผู้ใช้“ ไม่ได้ดูใต้พรม” เพื่อให้ได้การห่อหุ้ม

ใน Scheme มันเป็นธรรมเนียมในการกำหนดเพรดิเคตเช่นการfraction?จดจำค่าที่ให้โอกาสในการตรวจสอบอินพุต จากประสบการณ์ของฉันการใช้งานที่โดดเด่นคือการให้ผู้ใช้ตรวจสอบความถูกต้องของอินพุตหากเขาปลอมแปลงค่าแทนที่จะทำการตรวจสอบความถูกต้องของอินพุตในการเรียกใช้ไลบรารีแต่ละครั้ง

อย่างไรก็ตามมีกลยุทธ์หลายวิธีในการบังคับใช้ abstraction ของค่าที่ส่งคืนเช่นการคืนค่าการปิดซึ่งให้ค่าเมื่อนำไปใช้หรือส่งคืนการอ้างอิงถึงค่าในพูลที่จัดการโดยไลบรารี - แต่ฉันไม่เคยเห็นสิ่งใด ๆ ในทางปฏิบัติ

การห่อหุ้มไม่ใช่คุณสมบัติที่มาพร้อมกับ OOP ภาษาใด ๆ ที่สนับสนุนการทำให้เป็นโมดูลที่เหมาะสมมีอยู่

นี่เป็นวิธีที่คุณทำใน Haskell:

-- Rational.hs
module Rational (
    -- This is the export list. Functions not in this list aren't visible to importers.
    Rational, -- Exports the data type, but not its constructor.
    ratio,
    numerator,
    denominator
    ) where

data Rational = Rational Int Int

-- This is the function we provide for users to create rationals
ratio :: Int -> Int -> Rational
ratio num den = let (num', den') = reduce num den
                 in Rational num' den'

-- These are the member accessors
numerator :: Rational -> Int
numerator (Rational num _) = num

denominator :: Rational -> Int
denominator (Rational _ den) = den

reduce :: Int -> Int -> (Int, Int)
reduce a b = let g = gcd a b
             in (a `div` g, b `div` g)

ตอนนี้ในการสร้าง Rational คุณใช้ฟังก์ชั่นอัตราส่วนซึ่งบังคับให้ค่าคงที่ เนื่องจากข้อมูลไม่เปลี่ยนรูปคุณจึงไม่สามารถละเมิดค่าคงที่ได้ในภายหลัง

สิ่งนี้มีค่าใช้จ่ายสำหรับคุณบางอย่าง: ผู้ใช้ไม่สามารถใช้ deconstructing declaration แบบเดียวกับการใช้ตัวหารและตัวเศษ

คุณทำแบบเดียวกัน: สร้างตัวสร้างที่บังคับใช้ข้อ จำกัด และตกลงที่จะใช้ตัวสร้างนั้นเมื่อใดก็ตามที่คุณสร้างค่าใหม่

multiply lhs rhs = ReducedFraction (lhs.num * rhs.num) (lhs.denom * rhs.denom)

แต่ Karl ใน OOP คุณไม่จำเป็นต้องตกลงที่จะใช้ Constructor จริงๆเหรอ?

class Fraction:
  ...
  Fraction multiply(Fraction lhs, Fraction rhs):
    Fraction result = lhs.clone()
    result.num *= rhs.num
    result.denom *= rhs.denom
    return result

ในความเป็นจริงโอกาสสำหรับการละเมิดในลักษณะนี้มีน้อยลงใน FP คุณต้องวางคอนสตรัคเตอร์ให้คงอยู่เพราะไม่เปลี่ยนรูป ฉันหวังว่าผู้คนจะหยุดคิดถึงการห่อหุ้มร่างกายเพื่อป้องกันเพื่อนร่วมงานที่ไร้ความสามารถหรือขัดขวางความจำเป็นในการสื่อสารข้อ จำกัด มันไม่ได้ทำอย่างนั้น เพียง จำกัด สถานที่ที่คุณต้องตรวจสอบ โปรแกรมเมอร์ FP ที่ดีก็ใช้การห่อหุ้ม มันมาในรูปแบบของการสื่อสารฟังก์ชั่นที่ต้องการไม่กี่เพื่อทำการแก้ไขบางชนิด