良好的面向对象设计是否可以通过良好的关系数据库设计形式化? [英] Can good Object Orientated Design be formalised as good relational database design has been?

问题描述

在数据库世界中，我们进行了归一化.您可以从设计开始，按步骤进行操作，最后以正常的数据库形式结束.这是根据数据的语义完成的，可以认为是一系列的设计重构.

在面向对象的设计中，我们具有SOLID原则和各种其他针对优良设计的特别指南.

您是否认为可以为OO定义等效的普通形式，以便进行一系列重构步骤可以将一段程序代码(或因果关系不佳的OO设计)移至正确的(在某种意义上明确定义的意义) )具有相同功能的配方?

(请注意，很高兴制作此社区Wiki)

解决方案

这是可能的，但可能性很小.

上下文

首先，在关系模型出现的日子里，从事IT工作的人们受过更高的教育，他们尊重标准.计算机资源非常昂贵，人们一直在寻找使用这些资源的最佳方法.像科德(Codd)和伊达(Date)这样的人是高科技行业的巨头.

Codd并未发明归一化，我们早在Relational出现之前就对我们的非关系数据库进行了归一化.规范化是一种理论和实践，已发布为完全规范化原理".我们正在规范我们的程序，我们认为意外复制subrotine(方法)是一个严重的错误.如今，它被称为永不重复任何内容或不要重复自己"，但最近的版本并未承认背后的可靠学术理论，因此其功能尚未实现.

Codd所做的(在很多事情中)是专门为关系数据库定义了正式的范式.从那时起，这些技术就得到了改进和完善.但是他们也被非学术界劫持，目的是出售他们的装备.

由Codd和Chen发明并由Brown完成的数据库建模具有扎实的基础.在过去的25年中，它已经实现了标准化，并被许多扎根扎实的人进一步完善和发展.

面向对象的世界

让我们先了解OO之前的编程世界.我们有许多标准和约定，用于对程序进行建模以及特定于语言和平台的实现.您的问题在当时根本不适用.整个行业深知，数据库设计和程序设计是两种不同的科学，因此对它们使用不同的建模方法以及适用的任何标准.人们没有讨论是否实施标准，而是讨论了符合标准的程度；他们没有讨论是否为数据和程序建模的情况，而是讨论了对数据和程序进行建模的程度.这就是我们如何将人送上月球的方法，特别是在1969年.

OO的曙光

OO出现并自我介绍，就好像之前没有其他编程语言或设计方法一样.它没有使用现有方法并进行扩展或更改，而是否认了它们的存在.因此，毫不奇怪，花了20年的时间从​​头开始制定新的方法论，并将其逐步发展到不成熟的SOLID和Agile.您提出问题的原因.事实证明，在此期间，已经有二十多种此类方法学闪现并死亡.

即使UML可能是一个彻底的赢家，也适用于任何编程语言，但也遭受了同样的疾病.在试图否认存在成熟的方法论的情况下，它试图对所有人都是万能的.

行业缺陷

随着MS的到来，任何人都可以做任何事情"的态度(暗示:您不需要正规的教育或资格)，职业的素质和自豪感已荡然无存.人们现在从头开始发明事物，就好像地球上没有人做过一样.今天的IT行业的技术水平很低.您知道，但是大多数阅读这些页面的人不知道，有一种关系建模方法和一种标准.他们不建模，不执行.然后重新执行.并重新执行.如您所说的重构.

OO支持者

问题在于，提出了这些面向对象方法的人并不是专业人员中的巨头.他们只是非学术领域中最有声望的人.出名是由于出版书籍，而不是由于同行的认可. 不熟练且不了解的人 .他们的工具包中有 一把锤子 ，问题看起来像钉子.由于他们没有受到正规的教育，所以他们不知道数据库设计和程序设计实际上是两种不同的科学.数据库设计已经相当成熟，已经建立了牢固的方法和标准，并且他们只是将闪亮的新锤子应用于包括数据库在内的每个问题.

因此，由于他们不考虑编程方法和数据库方法，而是从头开始发明轮子，所以这些新方法进展非常缓慢.并且在类似的人群的帮助下，没有扎实的学术基础.

今天的程序有数百种未使用的方法.我们现在有程序可以检测到这一点.鉴于成熟的方法论，我们可以避免这种情况.瘦客户机不是要实现的目标，我们拥有一门科学可以做到这一点.现在，我们有了检测脏"数据并清理"数据的程序.而在数据库市场的高端市场中，我们根本不允许首先将脏"数据放入数据库中.

我同意您将数据库设计视为一系列重构，我理解您的意思.对我而言，这是一门科学(方法论，标准)，消除了必须进行重构的麻烦.即使接受重构，也是一个响亮的信号，表明较旧的编程方法是未知的.当前的面向对象方法还不成熟.这种危险使与面向对象的人员一起工作变得很烦人，是该方法本身会激发人们对一锤子"心态的信心，并且当代码破裂时，他们也站不住脚.当系统崩溃时，整个系统都将崩溃，这不是一个可以维修或更换的小部件.

接受Scott Ambler和Agile. Ambler花费20年的时间公开和大声地与数据库行业的巨头争论，反对Normalization.现在他有了敏捷，尽管还不成熟，但他有希望.但是它背后的秘密是规范化.他已切换曲目.而且由于他过去的战争，他无法坦诚地宣布这一点，并给予其他人应有的信誉，因此这仍然是一个秘密，您将不得不找出敏捷的基本面而不予以宣布.

预后

这就是为什么我说，鉴于过去20年来OO领域取得的进展很小；大约20种失败的OO方法论;由于方法的浅薄，当前的面向对象方法不太可能实现(单一)数据库设计方法的成熟度和接受度.至少还需要10年，更可能是20年，并且将由OO的一些替代来取代.

要使其成为可能，需要发生两件事:

1. OO的支持者需要接受正规的高等教育.编程科学的良好基础.当然，任何人都可以做任何事情，但是要做到伟大的事情，我们需要一个良好的基础.这将导致人们认识到不必要进行重构，可以通过科学消除重构.

2. 他们需要打破对其他编程方法和标准的否认.这将为在其上构建OO或为基础建立OO并将其合并为OO打开一扇门.这将导致一个坚实而完整的面向对象方法.

真实世界OO

很明显，我是根据经验说话的.在我们的大型项目中，我们使用成熟的分析和设计方法，一种用于数据库，另一种用于功能.当我们进入代码削减阶段时，我们让OO团队仅将其喜欢的对象用于其对象，这通常意味着UML.架构，结构或性能，膨胀软件，一把锤子或数百个未使用的对象都没有问题，因为所有这些都是由外部OO处理的.后来，在UAT期间，发现错误源或快速进行所需更改没有问题，因为整个结构具有记录在案的结构；可以更改.

In the database world, we have normalisation. You can start with a design, crank the steps and end up with a normal form of the database. This is done on the basis of the semantics of the data and can be thought of as a series of design refactorings.

In object orientated design, we have the SOLID principals and various other adhoc guidelines towards good design.

Do you think it is possible to define the equivalent of normal forms for OO, such that a series of refactoring steps could move a procedural piece of code (or poorly factored OO design) into a correct (in some well-defined sense) formulation with the same functionality?

(NB. Happy to make this community wiki)

解决方案

It is a possibility, but highly unlikely.

Context

First, in the days when the Relational Model came out, people who worked in IT were more educated and they esteemed standards. Computer resources were expensive, and people were always looking for the best way to use those resources. People like Codd and Date were giants in an industry where people were high tech.

Codd did not invent Normalisation, we were Normalising our non-relational databases long before Relational came along. Normalisation is a theory and practice, published as the Principle of Full Normalisation. We were Normalising our programs, we considered accidental duplication of a subrotine (method) a serious error. Nowadays it is known as Never Duplicate Anything or Don't Repeat Yourself, but the recent versions do not acknowledge the sound academic theory behind, and are therefore its power is unreallised.

What Codd did (among many things) was define formal Normal Forms specifically for Relational Databases. And these have progressed and been refined since then. But they have also been hijacked by non-academics for the purpose of selling their gear.

The database modelling that was invented by Codd and Chen, and finished by Brown had a solid grounding. In the last 25 years, its has achieved Standardisation and been further refined and progressed by many others who had solid grounding.

The World Before OO

Let's take the programming world before OO. We had many standards and conventions, for modelling our programs, as well as for language- and platform-specific implementation. Your question simply would not apply in those days. The entire industry understood deeply that database design and program design were two different sciences, and used different modelling methodologies for them, plus whatever standards applied. People did not discuss if they implemented standards, they discussed the extent to which they complied with standards; they did not discuss if they modelled their data and programs, they discussed the extent to which they modelled their data and programs. That is how we put men on the Moon, notably in 1969.

Dawn of OO

OO came along and presented itself as if no other programming language or design methodology existed before it. Instead of using existing methodologies and extending or changing them, it denied their existence. So, not surprisingly, it has taken 20 years to formulate the new methodologies from scratch and slowly progress them to the point of SOLID and Agile, which is not mature; the reason for your question. It is telling that more than twenty such methodologies have flashed up and died during that time.

Even UML, which could have been an outright winner, applicable to any programming language suffered the same disease. It tried to be everything to everyone while denying that mature methodologies existed.

Demise of the Industry

With the advent of MS, the attitude of "anyone can do anything" (implication: you do not need formal education or qualifications), that quality and pride of profession has been lost. People now invent things from scratch as if no one on the planet has ever done it before. The IT industry today is very low tech. You kow, but most people reading these pages do not know, that there is one Relational Modelling methodology, and one Standard. They do not model, the implement. Then re-implement. And re-implement. Re-factoring as you say.

OO Proponents

The problem was that the people who came up with these OO methods were not giants among professionals; they were simply the most vocal of an un-academic lot. Famous due to publishing books, not due to peer acknowledgement. Unskilled and unaware. They had One Hammer in their toolkit, and every problem looked like a nail. Since they were not formally educated they did not know that actually database design and program design are two different sciences; that database design was quite mature, had strongly established methodologies and standards, and they simply applied their shiny new hammer to every problem, including databases.

Therefore, since they were ignoring both programming methodologies and database methodologies, inventing the wheel from scratch, those new methodologies have progressed very slowly. And with assistance from a similar crowd, without sound academic basis.

Programs today have hundreds of methods that are not used. We now have programs to detect that. Whereas with the mature methodologies, we prevent that. Thin client was not a goal to be achieved, we had a science that produced it. We now have programs to detect "dirty" data and to "clean" it. Whereas in the upper end of the database market, we simply do not allow "dirty" data into the database in the first place.

I accept that you see database design as a series of re-factorings, I understand what you mean. To me it is a science (methodology, standards) that eliminates ever having to re-factor. Even the acceptance of re-factoring is loud signal that the older programming methodologies are unknown; that the current OO methodologies are immature. The danger, what makes it annoying to work with OO people, is that the methodology itself fosters a confidence in the One Hammer mentality, and when the code breaks, they have not one leg to stand on; when the system breaks, the whole system breaks, it is not one small piece that can be repaired or replaced.

Take Scott Ambler and Agile. Ambler spend 20 years publicly and vociferously arguing with the giants of the database industry, against Normalisation. Now he has Agile, which although immature, has promise. But the secret behind it it Normalisation. He has switched tracks. And because of his past wars, he cannot come out and declare that honestly, and give others due credit, so it remains a secret, and you are left to figure out Agile without its fundaments being declared.

Prognosis

That is why I say, given the evidenced small progress in the OO world over the last 20 years; the 20 or so OO methodologies that have failed; the shallowness of the approach, it is highly unlikely that the current OO methodologies will achieve the maturity and acceptance of the (singular) database design methodology. It will take at least another 10 years, more likely 20, and it will be over taken by some replacement for OO.

For it to be a possibility two things need to happen:

1. The OO proponents need formal tertiary education. A good grounding in the science of programming. Sure, anyone can do anything, but to do great things, we need a great grounding. That will lead to the understanding that re-factoring is not necessary, that it can be eliminated by science.

2. They need to break their denial of other programming methodologies and standards. That will open the door to either building OO on top of that, or taking the fundaments of that and merging it into OO. That will lead to a solid and complete OO methodology.

Real World OO

Obviously I speak from experience. On our large projects we use the mature analysis and design methodologies, one for database and another for function. When we get to the code-cutting stage, we let the OO team use whatever they like, for their objects only, which usually means UML. No problems with architecture or structure or performance or bloatware or One Hammer or hundreds of unused objects, because all that was taken care of outside OO. And later, during UAT, no problems with finding the source of bugs or making the required changes quickly, because the entire structure, has documented structure; the blocks can be changed.

这篇关于良好的面向对象设计是否可以通过良好的关系数据库设计形式化?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！