精华内容
下载资源
问答
  • 强双向依赖:即在父亲类中聚合了一个孩子,而孩子类中有聚合一个父亲,首这种强双向依赖的关系不仅在现实世界根本不存在,在面向对象世界也不可能存在:“父亲有一个孩子,孩子有一个父亲”涉及到了两个命题,一个是...

    问题:

    操作系统适配器层的适配器子系统需要向框架层发送键盘或者鼠标消息,c++代码如何发送这一类消息呢?让适配器子系统调用框架层的一个函数?这样一来操作系统适配器子系统必须依赖于框架层了,违背了每一层只能依赖于下面一层的原则。

    一个想法:让适配器子系统层和框架层双向依赖?


    双向依赖的问题:强双向依赖和若双向依赖

    强双向依赖:即在父亲类中聚合了一个孩子,而孩子类中有聚合一个父亲,首这种强双向依赖的关系不仅在现实世界根本不存在,在面向对象世界也不可能存在:“父亲有一个孩子,孩子有一个父亲”涉及到了两个命题,一个是因,一个是果,它们不能互为因果,在面向对象世界里,互为因果的代码则无法通过编译;

    头文件互相循环嵌入的代码也无法通过编译,这种情况类似于进程之间的死锁问题,编译器想要成功地编译父亲类,就会要求孩子类在父亲类之前被定义,而孩子类有要求父亲类咸鱼孩子类被定义---显然是自相矛盾的事情

    在C++语言,如果一定要实现双向依赖,那么至少有个一个方向的关系必须使用指针实现的若依赖关系;如果类A的头文件中只定义了类B的一个指针,没有使用类B中的任何属性和方法,C++编译器就不要求类B在类A之前被定义了,但是仍然要告诉编译器代码中存在一个名为B的一个类

    因为双向依赖对系统结构会造成软件代码之间,组件之间,包或者子系统之间的强烈耦合,对于需要适应不同需求和不同平台的系统,当相互依赖的两个包之间,任何一个包的接口发生变化,另外一个包就要相应地进行修改双向依赖使得操作系统的可扩展性,灵活性和可复用性荡然无存了,操作系统适配器层本身就是一个需要适应不同操作系统平台的软件层次,如果因为应用框架层的修改而导致了这一层的修改不是我们需要看到的,所以双向依赖这种方案不应该采用

    展开全文
  • 解决Maven项目相互依赖/循环依赖/双向依赖的问题

    解决Maven项目相互依赖/循环依赖/双向依赖的问题

    参考文章:

    (1)解决Maven项目相互依赖/循环依赖/双向依赖的问题

    (2)https://www.cnblogs.com/sharpest/p/7843348.html


    备忘一下。


    展开全文
  • 在使用spring data jpa 的过程中,有时候会有双向依赖的需求,如查询班级时需要级联查出班级内所有的学生,查询学生时需要查询学生所在的班级。体现在代码中便是 public class ClassOne implements Serializable{ ...

    在使用spring data jpa 的过程中,有时候会有双向依赖的需求,如查询班级时需要级联查出班级内所有的学生,查询学生时需要查询学生所在的班级。体现在代码中便是

    public class ClassOne implements Serializable{
    
        private static final long serialVersionUID = -15535318388014800L;
    
        private Long id;
    
        private String className;
    
        @OneToMany(mappedBy = "class", fetch = FetchType.LAZY)
        private Set<Student> students;
    
    }
    
    public class Student implements Serializable{
    
        private static final long serialVersionUID = -15535318388014800L;
    
        private Long id;
    
        private String studentName;
    
        @ManyToOne(cascade = CascadeType.ALL, fetch = FetchType.LAZY)
        @JoinColumn(name = "class_id")
        private ClassOne class;
    
    }

    这种情况在查询序列化的过程中,一端加载多端,多端有依赖一段,就会造成死循环的现象出现。解决这个问题通常由三种方法。

    1. 使用DTO对象,查询出信息后使用DTO对象进行封装,最后传给前台,在序列化之前将依赖关系去除掉。

    2.使用@JsonIgnore注解,在关联对象上添加这个注解,使在序列化是忽略掉这个字段。但是同时关联的对象也不会在josn数据中出现。

    3.@JsonIgnoreProperties注解,这个注解可以选择性的忽略固定字段,也就是说可以在查询班级的时候,忽略掉班级所级联出来的学生的班级字段,从而避免死循环。这个方法技能解决死循环,又能将级联到的数据返回到json。

    public class ClassOne implements Serializable{
    
        private static final long serialVersionUID = -15535318388014800L;
    
        private Long id;
    
        private String className;
    
        @JsonIgnoreProperties({"class"})
        @OneToMany(mappedBy = "class", fetch = FetchType.LAZY)
        private Set<Student> students;
    
    }
    
    public class Student implements Serializable{
    
        private static final long serialVersionUID = -15535318388014800L;
    
        private Long id;
    
        private String studentName;
    
        @ManyToOne(cascade = CascadeType.ALL, fetch = FetchType.LAZY)
        @JoinColumn(name = "class_id")
        @JsonIgnoreProperties({"students"})
        private ClassOne class;
    
    }

     

    展开全文
  •  第二个办法是下移,比如A和B互相依赖,同时它们都依赖C,那么可以将B和A相互依赖的那部分代码,移动到工程C里,这样一来,A和B相互之间都不依赖,只继续依赖C,也可以消除循环依赖    这两种重构方式都是...
    很​多​时​候​随​着​项​目​的​膨​胀​,模​块​会​越​来​越​多​,如​果​设​计​上​ 稍​有​不​慎​就​会​出​现​模​块​之​间​相​互​依​赖​的​情​况​。​这​对​于​使​用​Maven的​用​户​是​比​较​痛​苦​的​,因​为​出​现​模​块​之​间​相​互​依​赖​的​话​在​构​建​的​时​候​就​会​失​败​,Maven通​常​要​先​编​译​被​依​赖​的​模​块​,如​果​出​现​相​互​依​赖​Maven就​不​知​道​该​怎​么​办​了​。​下​图​描​述​了​三​个​Maven模​块​相​互​依​赖​的​场​景​: 

    图 1. A、​B、​C三​个​模​块​相​互​依​赖​


    图​中​模​块​C依​赖​于​模​块​B,模​块​B依​赖​于​模​块​A,而​模​块​A又​依​赖​于​模​块​C,这​样​就​出​现​了​相​互​依​赖​情​况​,如​果​运​行​mvn compile会​出​现​如​下​错​误​:
    [INFO] Scanning for projects... [ERROR] The projects in the reactor contain a cyclic reference: Edge between 'Ve rtex{label='org.kuuyee.sample:module-C:1.0-SNAPSHOT'}' and 'Vertex{label='org.ku uyee.sample:module-B:1.0-SNAPSHOT'}' introduces to cycle in the graph org.kuuyee .sample:module-B:1.0-SNAPSHOT --> org.kuuyee.sample:module-A:1.0-SNAPSHOT --> or g.kuuyee.sample:module-C:1.0-SNAPSHOT --> org.kuuyee.sample:module-B:1.0-SNAPSHO T -> [Help 1][ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit ch.[ERROR] Re-run Maven using the -X switch to enable full debug logging.[ERROR] [ERROR] For more information about the errors and possible solutions, please rea d the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectCycleEx ception
    1. 使​用​build-helper-maven-plugin解​决​相​互​依​赖​的​问​题​我​的​解​决​办​法​就​是​先​把​相​互​依​赖​的​模​块​整​合​在​一​起​,相​当​于​把​这​些​模​块​合​并​成​一​个​单​独​的​模​块​统​一​编​译​,
    如​下​图​:图 2. 合​并​A、​B、​C三​个​模​块​为​D模​块​


    这​样​就​产​生​了​一​个​合​并​模​块​D,我​们​把​它​当​做​一​个​辅​助​构​建​模​块​,然​后​让​A、​B、​C模​块​都​依​赖​于​D模​块​,这​样​的​话​就​可​以​成​功​编​译​A、​B和​C模​块​,
    如​下​图​: 图 3. 基​于​D模​块​来​分​别​编​译​A、​B、​C三​个​模​块​

    要​想​把​A、​B、​C三​个​模​块​整​合​在​一​起​编​译​,需​要​借​助​build-helper-maven-plugin插​件​,这​个​插​件​在​Maven构​建​周​期​提​供​一​些​辅​助​功​能​,下​面​列​出​插​件​的​提​供​的​功​能​列​表​: build-helper:add-source:添​加​更​多​的​构​建​源​码​目​录​ build-helper:add-test-source:添​加​更​多​的​测​试​源​码​目​录​ build-helper:add-resource:添​加​更​多​的​资​源​目​录​ build-helper:add-test-resource:添​加​更​多​的​测​试​资​源​目​录​ build-helper:attach-artifact:在​安​装​和​部​署​周​期​附​加​artifacts build-helper:maven-version:添​加​一​个​指​定​当​前​Maven版​本​的​属​性​ build-helper:parse-version:添​加​一​个​指​定​组​件​版​本​的​属​性​ build-helper:released-version:决​定​当​前​项​目​的​最​终​版​本​ build-helper:remove-project-artifact:从​本​地​资​源​库​中​移​除​项​目​的​artifacts build-helper:reserve-network-port:Reserve a list of random and unused network ports. 在​这​里​我​们​要​用​到​build-helper:add-source这​个​功​能​,将​模​块​A、​B、​C的​源​码​路​径​加​进​来​。​ 我​们​再​添​加​一​个​辅​助​模​块​D,在​辅​助​模​块​D中​使​用​build-helper-maven-plugin插​件​,然​后​让​模​块​A、​B、​C都​依​赖​于​辅​助​模​块​D,模​块​D的​POM模​型​如​下​: 例 1. 辅​助​模​块​D的​POM模​型​
    <project xmlns="http://maven.apache.org/POM/4.0.0"
    	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    	<parent>
    		<groupId>org.kuuyee.sample</groupId>
    		<artifactId>sample-parent</artifactId>
    		<version>1.0-SNAPSHOT</version>
    		<relativePath>../../pom.xml</relativePath>
    	</parent>
    	<modelVersion>4.0.0</modelVersion>
    	<groupId>org.kuuyee.sample</groupId>
    	<artifactId>module-D</artifactId>
    	<version>1.0-SNAPSHOT</version>
    	<packaging>jar</packaging>
    	<name>module-D</name>
    	<url>http://maven.apache.org</url>
    	<properties>
    		<project.build.sourceEncoding>
    			UTF-8
    		</project.build.sourceEncoding>
    		<module.a.src>../../module/module-A/src/main/java</module.a.src>
    		<module.b.src>../../module/module-B/src/main/java</module.b.src>
    		<module.c.src>../../module/module-C/src/main/java</module.c.src>
    	</properties>
    	<build>
    		<plugins><!-- 解决模块相互依赖,综合所有相互依赖代码统一编译 -->
    			<plugin>
    				<groupId>org.codehaus.mojo</groupId>
    				<artifactId>build-helper-maven-plugin</artifactId>
    				<executions>
    					<execution>
    						<id>add-source</id>
    						<phase>generate-sources</phase>
    						<goals>
    							<goal>add-source</goal>
    						</goals>
    						<configuration>
    							<sources>
    								<source>${module.a.src}</source>
    								<source>${module.b.src}</source>
    								<source>${module.c.src}</source>
    							</sources>
    						</configuration>
    					</execution>
    				</executions>
    			</plugin>
    		</plugins>
    	</build>
    	<dependencies>
    		<dependency>
    			<groupId>junit</groupId>
    			<artifactId>junit</artifactId>
    			<version>3.8.1</version>
    			<scope>test</scope>
    		</dependency>
    	</dependencies>
    </project>

    【转载地址】http://www.blogjava.net/kuuyee/archive/2011/06/28/353158.html

    maven处理循环依赖
     在多maven工程的项目里,如果工程间存在循环依赖,构建就会报错。本文介绍一下循环依赖要怎么处理
      
      1、什么是循环依赖
      
      如果工程A依赖工程B,工程B又依赖工程A,就会形成循环依赖。或者A依赖B,B依赖C,C依赖A,也是循环依赖
      
      总的来说,在画出工程依赖图之后,如果发现工程间的依赖连线形成了一个有向循环图,则说明有循环依赖的现象
      
      如果循环依赖发生在工程之间,则会影响构建,因为maven不知道应该先编译哪个工程。如果循环依赖发生在同一个工程的模块之间,虽然不影响编译,但是也是一种不好的实践,说明模块的设计有问题,应该避免
      
      如果在模块内部,有几个类互相调用的话,我觉得可能是正常的。比如观察者模式里面,Observer和Observable就是互相依赖的
      
      2、怎么解决循环依赖
      
      目前知道有2个办法可以解决
      
      第一个办法是用build-helper-maven-plugin插件来规避。比如A依赖B,B依赖C,C依赖A的情况。这个插件提供了一种规避措施,即临时地将工程A、B、C合并成一个中间工程,编译出临时的模块D。然后A、B、C再分别依赖临时模块D进行编译
      
      这种方法可以解决无法构建的问题,但是只是一个规避措施,工程的依赖关系依然是混乱的
      
      第二个办法是通过重构,从根本上消除循环依赖
      
      3、如何重构
      
      目前也知道2个重构的思路
      
      第一个办法是平移,比如A和B互相依赖,那么可以将B依赖A的那部分代码,移动到工程B中,这样一来,B就不需要继续依赖A,只要A依赖B就可以了,从而消除循环依赖
      
      第二个办法是下移,比如A和B互相依赖,同时它们都依赖C,那么可以将B和A相互依赖的那部分代码,移动到工程C里,这样一来,A和B相互之间都不依赖,只继续依赖C,也可以消除循环依赖
      
      这两种重构方式都是可行的,具体采用哪种方式要根据实际情况来判断。不管采取哪种方式,都需要对代码进行修改,有时候并不是那么容易的

    【转载地址】http://www.kaifajie.cn/kaifa_qita/7063.html



    展开全文
  • 或者A依赖B,B依赖C,C依赖A,也是循环依赖 总的来说,在画出工程依赖图之后,如果发现工程间的依赖连线形成了一个有向循环图,则说明有循环依赖的现象 如果循环依赖发生在工程之间,则会影响构建,因为maven不知道...
  • 重构 — 改善既有的类图设计条款1:将双向依赖改变成单向依赖黄国强 2008/5/6把这个条款放在第一个,是因为我认为,把设计中的所有双向依赖关系排除掉,是进行下一步重构工作的前提。图1如图1所有,图中有两个类,...
  • 背景我有以下几点:消防扩展元素类,木材延伸元素类,组成元素的Tile类.Tile类表示世界/屏幕/画布中的图块,并具有一些图形和逻辑功能.它合成一个Element对象,因为“世界”中的每个图块都是由某种物质(=元素)组成的....
  • 背景 我有以下几点: 消防扩展元素类, 木材延伸元素类, 组成元素的Tile类. ...Tile类表示世界/屏幕/画布中的图块,并具有一些图形和逻辑功能. 它合成一个Element对象,因为“世界”中的每个图块都是由某种物质(=...
  • 下面是一个简单的测试例子,用于说明一下如何做到相互依赖而编译生成动态库的方法 1、首先编译生成动态库 首先定义头文件:test.h #ifndef XXX_TEST_H___ #define XXX_TEST_H___ /* 由link的库实现 */ extern void ...
  • 所以如果希望用到新性能的Jackson,请将原来的maven依赖改为以下的依赖。 下文中的jackson-2-version是指特定的版本,当前的稳定版本为 2.8.9 。想要了解最新的版本情况还请去项目主页或是maven官网上查看。但是如果...
  • 所以如果希望用到新性能的Jackson,请将原来的maven依赖改为以下的依赖。 下文中的jackson-2-version是指特定的版本,当前的稳定版本为 2.8.9 。想要了解最新的版本情况还请去项目主页或是maven官网上查看。但是...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,849
精华内容 1,939
关键字:

双依赖