pith. sign in

arxiv: 2606.27258 · v1 · pith:HMWPG2YHnew · submitted 2026-06-25 · 💻 cs.SE · cs.HC· cs.PL

Beyond Objects

Pith reviewed 2026-06-26 02:57 UTC · model grok-4.3

classification 💻 cs.SE cs.HCcs.PL
keywords object orientationsoftware modularityfunctional partitioningdomain modelingsoftware design principlescode organization
0
0 comments X

The pith

Object orientation's core principle of partitioning functionality by domain individuals inevitably produces fragmented and conflated code.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper contends that object orientation rests on a partitioning rule that assigns pieces of system behavior to modules each tied to one real-world entity. This rule is presented as neither natural nor easy to apply cleanly, and it directly generates the scattering of related functions across multiple modules and the mixing of unrelated functions inside single modules. Later ideas in software engineering that tried to repair these issues by building atop object orientation therefore could not succeed, because the source of the trouble lies in the original partitioning rule itself. The recommended response is to drop the rule altogether and adopt a different organization in which the modeling of domain individuals is kept separate from the modules that divide up functionality.

Core claim

A core principle of object orientation -- that the functionality of a system can be partitioned amongst objects that correspond to individuals in the problem domain -- has influenced how software has been specified, designed and implemented for more than fifty years. Later developments in software engineering sought to build on this principle. But in fact this partitioning is neither natural nor straightforward, and the problems that these later developments sought to mitigate -- the fragmentation and conflation of functionality -- were often, in fact, the inevitable consequences of this founding principle. An easier path to addressing these problems therefore starts by going back, abandonin

What carries the argument

The partitioning principle that assigns system functionality to objects mirroring problem-domain individuals.

If this is right

  • Any design that follows the object-orientation partitioning rule will continue to exhibit scattered functionality and mixed responsibilities.
  • Extensions such as design patterns or aspect-oriented techniques cannot eliminate the root problems because they retain the original partitioning.
  • Adopting an approach that decouples domain individuals from functional modules will produce partitions of behavior that are both more coherent and easier to maintain.
  • Software specifications and implementations can be organized without forcing every functional grouping to align with a single domain entity.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If the claim holds, many observed difficulties in large codebases may trace back to the initial choice of partitioning rule rather than to later implementation errors.
  • The argument points toward exploring alternative ways of grouping behavior that treat domain modeling as a separate concern from functional decomposition.
  • One could test the idea by taking an existing object-oriented system, re-partitioning its functions without reference to domain individuals, and checking whether measurable reductions in scattering or mixing occur.

Load-bearing premise

That the fragmentation and conflation problems are inevitable consequences of the object-orientation partitioning principle itself rather than arising from other factors in how systems are specified or implemented.

What would settle it

A working large-scale software system built on the object-orientation partitioning principle that nevertheless shows neither fragmentation of related functions across modules nor conflation of unrelated functions inside modules would falsify the central claim.

Figures

Figures reproduced from arXiv: 2606.27258 by Daniel Jackson.

Figure 1
Figure 1. Figure 1: The Reserving concept [PITH_FULL_IMAGE:figures/full_fig_p019_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: The Availability concept sync makeReservation when Requesting.reserve (restaurant, time, date, partySize, session) where Availability._getAvailableSlot (time, date, partySize) : (slot) UserAuthentication._getUser (session) : (user) Karma._inGoodStanding (user) then Reserving.reserve (user, slot, time, date, partySize) sync punishNoShow when Reserving.noShow (reservation) where reservation.user = user in Re… view at source ↗
Figure 3
Figure 3. Figure 3: Sample synchronizations [PITH_FULL_IMAGE:figures/full_fig_p020_3.png] view at source ↗
read the original abstract

A core principle of object orientation -- that the functionality of a system can be partitioned amongst objects that correspond to individuals in the problem domain -- has influenced how software has been specified, designed and implemented for more than fifty years. Later developments in software engineering sought to build on this principle. But in fact this partitioning is neither natural nor straightforward, and the problems that these later developments sought to mitigate -- the fragmentation and conflation of functionality -- were often, in fact, the inevitable consequences of this founding principle. An easier path to addressing these problems therefore starts by going back, abandoning object orientation, and replacing it with an alternative approach that decouples the individuals of the problem domain from the modules that partition functionality.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 0 minor

Summary. The manuscript argues that the foundational principle of object orientation—partitioning system functionality among objects that correspond to individuals in the problem domain—has shaped software specification, design, and implementation for over fifty years. It claims this partitioning is neither natural nor straightforward, and that the fragmentation and conflation of functionality (which later developments sought to mitigate) are inevitable consequences of the principle itself. The paper concludes that addressing these issues requires abandoning object orientation in favor of an alternative approach that decouples domain individuals from the modules that partition functionality.

Significance. If the central claim holds, the result would have substantial significance for software engineering by providing a foundational critique of object-oriented design and motivating a paradigm-level shift away from domain-individual-based modularization toward decoupled alternatives. This could influence long-term methodology development, tool design, and education in the field.

major comments (1)
  1. [Abstract] Abstract: The assertion that fragmentation and conflation 'were often, in fact, the inevitable consequences of this founding principle' is presented without derivation, logical steps, enumeration of possible realizations of the partitioning principle, or counterfactual analysis showing why non-fragmenting or non-conflating module structures are impossible while still obeying the core principle of correspondence to domain individuals. This makes the necessity claim difficult to assess as demonstrated rather than interpretive.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for their review and the opportunity to clarify the presentation of our central claim. We address the single major comment below.

read point-by-point responses
  1. Referee: [Abstract] Abstract: The assertion that fragmentation and conflation 'were often, in fact, the inevitable consequences of this founding principle' is presented without derivation, logical steps, enumeration of possible realizations of the partitioning principle, or counterfactual analysis showing why non-fragmenting or non-conflating module structures are impossible while still obeying the core principle of correspondence to domain individuals. This makes the necessity claim difficult to assess as demonstrated rather than interpretive.

    Authors: The abstract is intentionally concise, but the full manuscript supplies the requested derivation through concrete examples of domain-individual correspondence (e.g., the forced distribution of cross-cutting concerns and the forced bundling of unrelated behaviors) together with an enumeration of alternative module structures that remain consistent with the core principle yet still produce fragmentation or conflation. We agree that the abstract would benefit from a brief pointer to this supporting reasoning. We will therefore revise the abstract to include a short indication of the logical steps and a reference to the relevant sections. revision: yes

Circularity Check

0 steps flagged

No circularity; interpretive historical argument lacks derivation chain or self-referential reductions

full rationale

The paper advances a conceptual critique of object orientation as a partitioning principle, asserting that fragmentation and conflation are inevitable consequences. No equations, fitted parameters, predictions, or self-citations appear in the provided text. The central claim is presented as an interpretive conclusion from historical developments rather than a reduction by construction to inputs, self-definition, or author-prior uniqueness theorems. The argument is self-contained as a position paper without load-bearing steps that equate outputs to inputs by fiat.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The paper is a position paper whose central claim rests on interpretive assumptions about software engineering history and the inevitability of certain problems; no quantitative parameters or new entities are introduced.

axioms (1)
  • domain assumption Object orientation is founded on the principle that functionality can be partitioned amongst objects corresponding to individuals in the problem domain
    This is presented in the abstract as the core principle that has influenced software for more than fifty years.

pith-pipeline@v0.9.1-grok · 5627 in / 1244 out tokens · 55732 ms · 2026-06-26T02:57:46.527685+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

56 extracted references · 20 canonical work pages

  1. [1]

    In: IFIP Working Conference on Data Base Manage- ment

    Abrial, J.R.: Data semantics. In: IFIP Working Conference on Data Base Manage- ment. pp. 1–60. North-Holland (1974)

  2. [2]

    Cambridge University Press (1996)

    Abrial, J.R.: The B-Book: Assigning Programs to Meanings. Cambridge University Press (1996)

  3. [3]

    Cambridge University Press, Cambridge, UK (2010)

    Abrial, J.R.: Modeling in Event-B: System and Software En- gineering. Cambridge University Press, Cambridge, UK (2010). https://doi.org/10.1017/CBO9781139195885

  4. [4]

    In: On the Con- struction of Programs

    Abrial, J.R., Schuman, S.A., Meyer, B.: Specification language. In: On the Con- struction of Programs. Cambridge University Press (1980)

  5. [5]

    Information and Software Technology36(1), 43–51 (1994)

    Ainsworth, M., Cruickshank, A.H., Wallis, P.J.L., Groves, L.J.: Viewpoint spec- ification and z. Information and Software Technology36(1), 43–51 (1994). https://doi.org/10.1016/0950-5849(94)90007-8

  6. [6]

    https://github.com/winterrrrrff/realWorld-server

    Anonymous: Realworld example app repository. https://github.com/winterrrrrff/realWorld-server

  7. [7]

    In: Black, A.P

    Bierman, G.M., Wren, A.: First-class relationships in an object-oriented language. In: Black, A.P. (ed.) ECOOP 2005 – Object-Oriented Programming. Lecture Notes in Computer Science, vol. 3586, pp. 262–286. Springer, Glasgow, UK (2005). https://doi.org/10.1007/11531142_12

  8. [8]

    Game Developers Conference (GDC) (2002), http://gamedevs.org/uploads/data-driven-game-object-system.pdf, slides available online

    Bilas, S.: A data-driven game object system. Game Developers Conference (GDC) (2002), http://gamedevs.org/uploads/data-driven-game-object-system.pdf, slides available online

  9. [9]

    Springer (2005)

    Bjørner, D.: Software Engineering 1: Abstraction and Modeling. Springer (2005)

  10. [10]

    Ben- jamin/Cummings (1991) Beyond Objects 25

    Booch, G.: Object-Oriented Analysis and Design with Applications. Ben- jamin/Cummings (1991) Beyond Objects 25

  11. [11]

    BusinessWeek Magazine (September 30, 1991)

    BusinessWeek: Software made simple. BusinessWeek Magazine (September 30, 1991)

  12. [12]

    ACM Transactions on Database Systems1(1), 9–36 (1976)

    Chen, P.P.S.: The entity-relationship model: Toward a unified view of data. ACM Transactions on Database Systems1(1), 9–36 (1976). https://doi.org/10.1145/320434.320440

  13. [13]

    Codd , title =

    Codd, E.F.: A relational model of data for large shared data banks. Communica- tions of the ACM13(6), 377–387 (1970). https://doi.org/10.1145/362384.362685

  14. [14]

    Codd, E.F.: Further normalization of the data base relational model. Tech. Rep. RJ909, IBM Research (1972)

  15. [15]

    Cook,W.R.:Object-orientedprogrammingversusabstractdatatypes.In:Proceed- ings of the REX School/Workshop on Foundations of Object-Oriented Languages. p. 151–178. Springer-Verlag, Berlin, Heidelberg (1990)

  16. [16]

    In: ACM Queue (2009)

    Coplien, J.O., Reenskaug, T.: Dci architecture: A new vision of object-oriented programming. In: ACM Queue (2009). https://doi.org/10.1145/1594209.1594214

  17. [17]

    (eds.): Structured Programming

    Dahl, O.J., Dijkstra, E.W., Hoare, C.A.R. (eds.): Structured Programming. Aca- demic Press (1972)

  18. [18]

    In: IFIP Working Conference on Simulation Programming Languages

    Dahl, O.J., Nygaard, K.: Simula: An algol-based simulation language. In: IFIP Working Conference on Simulation Programming Languages. North-Holland (1966)

  19. [19]

    In: IFIP International Conference on Open Distributed Processing (1995)

    Derrick, J., Bowman, H., Steen, M.: Maintaining cross-viewpoint consistency using z. In: IFIP International Conference on Open Distributed Processing (1995)

  20. [20]

    In: Selected Writings on Com- puting: A Personal Perspective

    Dijkstra, E.W.: On the role of scientific thought. In: Selected Writings on Com- puting: A Personal Perspective. Springer (1982), originally presented at the IFIP Congress 1974

  21. [21]

    Addison-Wesley (2003)

    Evans, E.: Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley (2003)

  22. [22]

    International Journal of Software Engineering and Knowledge Engineering2(1), 31–57 (1992)

    Finkelstein, A., Kramer, J., Nuseibeh, B., Finkelstein, L., Goedicke, M.: View- points: A framework for integrating multiple perspectives in system development. International Journal of Software Engineering and Knowledge Engineering2(1), 31–57 (1992). https://doi.org/10.1142/S0218194092000038

  23. [23]

    Addison-Wesley (1994)

    Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley (1994)

  24. [24]

    https://codebase.show/projects/realworld

    Gothinkster: Realworld example apps. https://codebase.show/projects/realworld

  25. [25]

    MIT Press (1986)

    Guttag, J.V., Liskov, B.: Abstraction and Specification in Program Development. MIT Press (1986)

  26. [26]

    (ed.): Specification Case Studies

    Hayes, I.J. (ed.): Specification Case Studies. Prentice Hall, second edn. (2001)

  27. [27]

    In: Proceedings of the Z User Meeting

    Hayes, I.J., Wildman, L.: Towards libraries for z. In: Proceedings of the Z User Meeting. Workshops in Computing, Springer (1992)

  28. [28]

    In: Proceedings of the 3rd International Joint Conference on Artificial Intelligence

    Hewitt, C., Bishop, P., Steiger, R.: A universal modular actor formalism for ar- tificial intelligence. In: Proceedings of the 3rd International Joint Conference on Artificial Intelligence. p. 235–245. IJCAI’73, Morgan Kaufmann Publishers Inc., San Francisco, CA, USA (1973)

  29. [29]

    Prentice Hall (1985)

    Hoare, C.A.R.: Communicating Sequential Processes. Prentice Hall (1985)

  30. [30]

    In: Jackson, D

    Hoare, C.A.R.: The michael jackson design technique: A study of the theory with applications. In: Jackson, D. (ed.) ICSE Workshop: A Tribute to Michael Jack- son (2009), workshop held in conjunction with the International Conference on Software Engineering (ICSE)

  31. [31]

    https://essenceofsoftware.com, blog post (2025) 26 D

    Jackson, D.: What you see is what it does. https://essenceofsoftware.com, blog post (2025) 26 D. Jackson

  32. [32]

    ACM Transac- tions on Software Engineering and Methodology4(4), 335–372 (1995)

    Jackson, D.: Structuring z specifications with views. ACM Transac- tions on Software Engineering and Methodology4(4), 335–372 (1995). https://doi.org/10.1145/226241.226249

  33. [33]

    Princeton, Princeton, NJ (2021)

    Jackson, D.: The Essence of Software: Why Concepts Matter for Great Design. Princeton, Princeton, NJ (2021)

  34. [34]

    In: Proceedings of the 17th international conference on Software engineering

    Jackson, M.: The world and the machine. Proceedings of the 17th Inter- national Conference on Software Engineering (ICSE) pp. 283–292 (1995). https://doi.org/10.1145/225014.225041

  35. [35]

    Academic Press, London (1975)

    Jackson, M.A.: Principles of Program Design. Academic Press, London (1975)

  36. [36]

    Prentice Hall, Englewood Cliffs, NJ (1983)

    Jackson, M.A.: System Development. Prentice Hall, Englewood Cliffs, NJ (1983)

  37. [37]

    https://doi.org/10.1145/154766.155364, https://doi.org/10.1145/154766.155364

    Kay, A.C.: The early history of smalltalk (1993). https://doi.org/10.1145/154766.155364, https://doi.org/10.1145/154766.155364

  38. [38]

    In: ECOOP

    Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J.M., Irwin, J.: Aspect-oriented programming. In: ECOOP. LNCS, vol. 1241, pp. 220–

  39. [39]

    https://doi.org/10.1007/BFb0053381

    Springer (1997). https://doi.org/10.1007/BFb0053381

  40. [40]

    Computers & Mathematics with Applications 23(2), 1–50 (1992)

    Lehmann, F.: Semantic networks. Computers & Mathematics with Applications 23(2), 1–50 (1992). https://doi.org/https://doi.org/10.1016/0898-1221(92)90135- 5, https://www.sciencedirect.com/science/article/pii/0898122192901355

  41. [41]

    Communications of the ACM20(8), 564–576 (1977)

    Liskov, B., Snyder, A., Atkinson, R., Schaffert, C.: Abstraction mech- anisms in clu. Communications of the ACM20(8), 564–576 (1977). https://doi.org/10.1145/359763.359789

  42. [42]

    In: ACM SIGPLAN Symposium on Very High Level Languages

    Liskov, B., Zilles, S.: Programming with abstract data types. In: ACM SIGPLAN Symposium on Very High Level Languages. pp. 50–59 (1974)

  43. [43]

    Liskov and Jeannette M

    Liskov, B.H., Wing, J.M.: A behavioral notion of subtyping. ACM Trans- actions on Programming Languages and Systems16(6), 1811–1841 (1994). https://doi.org/10.1145/197320.197383

  44. [44]

    In: Proceedings of the 2025 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software

    Meng,E.,Jackson,D.:Whatyouseeiswhatitdoes:Astructuralpatternforlegible software. In: Proceedings of the 2025 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software. p. 178–193. Onward! ’25, Association for Computing Machinery, New York, NY, USA (2025). https://doi.org/10.1145/3759429.3762628

  45. [45]

    Prentice Hall (1988)

    Meyer, B.: Object-Oriented Software Construction. Prentice Hall (1988)

  46. [46]

    Neighbors, J.M.: Software Construction Using Components. Ph.D. thesis, Univer- sity of California, Irvine (1980)

  47. [47]

    Proceedings of OOPSLA pp

    Ossher, H., Harrison, W.: Subject-oriented programming: A cri- tique of pure objects. Proceedings of OOPSLA pp. 411–428 (1993). https://doi.org/10.1145/165854.165932

  48. [48]

    Communications of the ACM15(12), 1053–1058 (1972)

    Parnas, D.L.: On the criteria to be used in decomposing systems into modules. Communications of the ACM15(12), 1053–1058 (1972). https://doi.org/10.1145/361598.361623

  49. [49]

    IEEE Transactions on Software EngineeringSE-5(2), 128–138 (1979)

    Parnas, D.L.: Designing software for ease of extension and contrac- tion. IEEE Transactions on Software EngineeringSE-5(2), 128–138 (1979). https://doi.org/10.1109/TSE.1979.234169

  50. [50]

    Manning (1996)

    Reenskaug,T.,Wold,P.,Lehne,O.A.:WorkingwithObjects:TheOOramSoftware Engineering Method. Manning (1996)

  51. [51]

    Prentice Hall (1991)

    Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W.: Object- Oriented Modeling and Design. Prentice Hall (1991)

  52. [52]

    In: In- ternational Conference on Formal Engineering Methods

    Silva, R., Butler, M.: Shared event composition/decomposition in event-b. In: In- ternational Conference on Formal Engineering Methods. LNCS, Springer (2010)

  53. [53]

    Sutherland, I.E.: Sketchpad: A Man-Machine Graphical Communication System. Ph.D. thesis, MIT (1963) Beyond Objects 27

  54. [54]

    In: Boehm, B.W., Gar- lan, D., Kramer, J

    Tarr, P.L., Ossher, H., Harrison, W.H., Sutton, S.M.J.: N degrees of sep- aration: Multi-dimensional separation of concerns. In: Boehm, B.W., Gar- lan, D., Kramer, J. (eds.) Proceedings of the 21st International Conference on Software Engineering. pp. 107–119. ACM, Los Angeles, CA, USA (1999). https://doi.org/10.1145/302405.302457

  55. [55]

    In: Conference Proceedings on Object-Oriented Programming Systems, Languages and Applications

    Wirfs-Brock, R., Wilkerson, B.: Object-oriented design: a responsibility-driven ap- proach. In: Conference Proceedings on Object-Oriented Programming Systems, Languages and Applications. p. 71–75. OOPSLA ’89, Association for Comput- ing Machinery, New York, NY, USA (1989). https://doi.org/10.1145/74877.74885, https://doi.org/10.1145/74877.74885

  56. [56]

    Prentice Hall (1989)

    Yourdon, E.: Modern Structured Analysis. Prentice Hall (1989)